EngineeringMechanical EngineeringData
SOLIDWORKS File References, Search Paths & Data Portability
A design is not a set of files. It is a graph of files that point at each other, and almost every data-integrity problem an engineering function encounters is a broken edge in that graph. Ordinary file operations — rename, move, copy — are not safe against it.
- Group · Data
- Series · Administration
- Baseline · SOLIDWORKS 2026
- Reading · 18 min
01 The Reference Graph
A design is not a set of files. It is a graph of files that point at each other, and almost every data-integrity problem an engineering function encounters is a broken edge in that graph.
An assembly holds references to its components. A drawing holds references to the models it documents. A derived or mirrored part holds a reference to its parent. An in-context feature holds a reference to the geometry it was built against. None of this is stored inside the referencing file as geometry — it is stored as a pointer, and a pointer that no longer resolves produces a document that opens with missing content.
The consequence worth internalising is that ordinary file operations are not safe. Renaming a part in the file explorer, moving a folder, or copying a project directory are all operations that a general-purpose filing system treats as trivial and that this data model does not.
The reference model and resolution behaviour described here are stable across releases. Specific tool names, dialogue locations and export format options change; verify against the documentation for the release in service.
02 How References Resolve
When a referencing document opens, each pointer must be resolved to an actual file. Understanding the order in which that resolution is attempted explains most of the surprising behaviour engineers report.
Resolution is not a single lookup against a stored absolute path. Several candidates are considered in sequence — a document already open in the session, the location recorded in the referencing file, locations relative to that referencing file, and configured search folders. The first match wins.
The resolution routine returns the first candidate it finds with the expected name. It does not verify that the file is the one originally referenced. Where two files share a name, an assembly can silently resolve against the wrong one and open without any indication of a problem.
This is the single most damaging failure mode in a file-based environment, because the document appears correct. It is discovered when a bill of materials contains an unexpected item, or when a part is manufactured to the wrong geometry.
Search folders
Configured search folders extend resolution to locations beyond the recorded path. They are useful for shared library content and destructive for everything else. A search folder pointing at a broad location — a whole project drive, or a personal working directory — turns every unresolved reference into a lottery across everything in that tree.
- Keep search folders narrow. Shared library locations only, never general working areas.
- Keep them consistent. Set through the deployment image and locked, so resolution behaves identically on every workstation.
- Review the list. Search folders accumulate. An entry added for one project three years ago is still influencing resolution today.
- Order matters. Where several folders are configured, the sequence determines which candidate is found first.
03 Operations That Break References
| Operation | Performed in the file explorer | Performed with reference-aware tooling |
|---|---|---|
| Rename a part | Breaks every reference to it | References updated |
| Move a file | May resolve via search, may not | References updated |
| Copy an assembly for reuse | Copy still points at the originals | Copies references as a set |
| Move a whole folder tree | Relative references survive; absolute may not | Predictable |
| Delete a part | Silent breakage discovered later | Dependants identified first |
| Replace a component | Not possible safely | Handled as a modelling operation |
The most common and most damaging error: an engineer copies a project folder in the file explorer to start a similar job. The copied assembly still points at the original parts, so editing what appears to be a new design modifies the original one.
This is not detected at the time. It is detected when the original project's drawings no longer match its parts. Establish reference-aware copying as the only sanctioned way to reuse a design, and make sure every engineer knows why.
Safe operations
Reference-aware tooling exists for exactly these operations — rename, move, replace, and copy-with-references. Where no data management system is in place, this tooling is the only safe path and its use should be mandatory rather than advisory. Where a vault is in place, these operations are performed inside the vault and reference integrity is maintained as a property of the system.
04 In-Context References
Geometry driven by other geometry across a file boundary. Powerful, and the category most likely to produce a design that changes when nobody changed it.
An in-context feature is built against geometry belonging to another component, in the context of a particular assembly. The referencing part carries a dependency not just on the referenced part but on the assembly the relationship was created in. That triangular dependency is what makes the behaviour hard to reason about.
Where it goes wrong
- Unintended propagation. A change to the parent updates the child, in every assembly the child appears in — including ones where the update is wrong.
- Context loss. Opening the child outside its defining assembly leaves the reference unresolved, and the feature may behave unpredictably.
- Circularity. Two parts referencing each other produce rebuild behaviour that depends on evaluation order and is effectively non-deterministic.
- Copy contamination. A copied assembly retains in-context references to the original components unless deliberately broken, so the copy drives the original.
- Invisible coupling. Nothing in the file explorer indicates that a part is driven by another. The dependency is only visible inside the application.
Permit in-context references where the relationship is genuinely a design intent — a bracket that must follow a mounting face, a cover matching an aperture. Require that the relationship is documented, that the parent is identified, and that the reference is locked or broken once the design is released.
Prohibit them across project boundaries and into shared library content entirely. A library component driven by one project's geometry will eventually be updated by that project and break every other assembly using it.
Skeleton and layout approaches
Where cross-component relationships are extensive, a controlled alternative is to drive everything from a single skeleton or layout that owns the shared geometry. Components reference the skeleton rather than each other. The dependency graph becomes a star rather than a mesh, which is dramatically easier to reason about, to change safely and to hand to someone else.
05 Duplicate Filenames
The most consequential naming decision an organisation makes, and one usually made by accident.
Because resolution returns the first candidate with the matching name, two different files sharing a name make the graph ambiguous. Which one an assembly resolves against depends on what is already open, where the referencing file sits, and how search folders are ordered — none of which is stable or visible.
Descriptive naming
Files named for what they are — bracket.sldprt, cover plate.sldprt — guarantee collisions as soon as a second project needs a bracket.
Control: unique identifiers as filenames, with description carried in properties.
Copy-and-modify workflows
Copying a project folder produces a second set of identically named files in a different location.
Control: reference-aware copying with renaming applied as part of the same operation.
Imported and supplier data
Supplier models arrive with generic names and are dropped into project folders as received.
Control: a controlled purchased-component location with your own naming applied on receipt.
A data management system enforces filename uniqueness across the vault, which is one of the least discussed and most valuable things it does. Without one, uniqueness must be maintained by convention — and convention degrades. Adopting unique identifiers as filenames early is inexpensive; retrofitting them across an existing estate is a migration project.
06 Transmittal & Data Portability
Sending native data
Sending an assembly means sending the entire graph beneath it. Attaching the assembly file alone produces a document the recipient cannot open. The reference-aware collection tool gathers a document and every file it depends on into a single folder or archive, optionally flattening the structure and renaming as it goes.
Use it for every native transmittal without exception, including internal transfers between sites. It is also the correct mechanism for taking a design to a machine outside the normal environment — an engineer working offsite, or a supplier who works in the same application.
Neutral formats
| Purpose | Typical format | Carries | Notes |
|---|---|---|---|
| Manufacture from solid geometry | Solid model exchange format | Exact solid geometry, assembly structure | The default for supplier transmittal where geometry must be modifiable |
| Kernel-level exchange | Modelling kernel format | Exact geometry with high fidelity | Best fidelity where the recipient uses a compatible kernel |
| Fabrication from flat pattern | 2D vector format | Flat pattern outline, bend lines | Confirm bend allowance convention with the fabricator |
| Review and markup | Lightweight viewer or 3D document format | Geometry for viewing, measurement, annotation | Recipient needs no CAD application; not for manufacture |
| Issued documentation | Fixed-layout document format | Drawing as issued | The controlled deliverable; native drawings are working files |
| Long-term retention | Neutral geometry plus fixed-layout drawings | Geometry and documentation independent of the application | The only form guaranteed readable decades later |
File format progression is one-way: a file saved in a newer major version cannot be opened in an older one. Over a twenty-year retention obligation, that guarantees an eventual migration or a loss.
For anything with a long retention requirement — regulated products, long-lived assets, contractual obligations — generate a neutral geometry export and a fixed-layout drawing set at release, and retain those alongside the native files. This is cheap at release and impossible to reconstruct later.
07 Where a Vault Changes the Picture
Most of this page describes problems that a data management system substantially removes. That is worth stating plainly, because it is the strongest practical argument for introducing one.
| Concern | File-based | Vault-managed |
|---|---|---|
| Filename uniqueness | By convention | Enforced |
| Rename and move | Requires specific tooling, easily bypassed | Reference-safe by construction |
| Where-used visibility | Not readily available | Queryable before any change |
| Copy for reuse | Breaks unless done deliberately | Explicit copy-with-references operation |
| Concurrent editing | Last write wins | Check-out prevents it |
| Accidental deletion | Permanent | Recoverable from history |
| Search path ambiguity | A standing risk | Resolution is deterministic within the vault |
None of this removes the need for the practices described above — in-context reference policy, neutral format retention and naming discipline all remain necessary. What a vault removes is the class of failure that arises from ordinary file operations, which is the largest single source of data-integrity incidents in an unmanaged environment.
08 Reference Integrity Checklist
- Unique filenames. Files named by unique identifier, with description carried in properties rather than in the filename.
- Search folders narrow and locked. Shared library locations only, deployed through the settings file, reviewed periodically.
- Reference-aware tooling mandated. Rename, move, replace and copy performed only with tooling that maintains references.
- Copy-for-reuse prohibited in the file explorer. The sanctioned reuse path is documented and understood by every engineer.
- In-context policy defined. Permitted within a design where documented; prohibited across projects and into library content.
- Released references locked or broken. External references resolved before release rather than left live.
- Purchased components controlled. Supplier models renamed and placed in a controlled location on receipt.
- Transmittal via collection tooling. Native data always sent as a collected set, including internally.
- Neutral exports at release. Geometry and fixed-layout drawings generated and retained where a long retention obligation exists.
- Archive format decided. Long-term retention does not rely on the native format remaining readable.
09 Frequently Asked Questions
An assembly opens with missing components. What is the diagnostic sequence?
Establish what the assembly is actually looking for before moving anything. The reference listing shows each expected file and its recorded path, which distinguishes a file that has moved from one that has been renamed or deleted.
Then check whether a file of that name exists elsewhere — because if it does, the more serious possibility is that other assemblies have already resolved against the wrong one. Repair the reference with reference-aware tooling rather than by copying a file into place, which merely creates another duplicate and defers the problem.
How do we stop engineers copying project folders to start new jobs?
Explanation works better than prohibition, because the behaviour is entirely reasonable in any other filing context. Show an engineer once that their copied assembly is editing the original parts and the practice generally stops.
Then make the sanctioned path at least as convenient. A documented reuse procedure using reference-aware copying, or a vault operation that copies a design with new identifiers in one step, removes the incentive. A prohibition without a convenient alternative gets worked around.
Should we allow in-context references at all?
Banning them entirely is a defensible position and some organisations take it, at the cost of losing genuine design-intent relationships that would otherwise be captured and maintained automatically.
The more common position is to permit them within a single design where the relationship is real, require documentation of the parent, and resolve or lock them at release. What should be prohibited without exception is in-context references crossing project boundaries or reaching into shared library content — those produce breakage that is remote in both time and place from the change that caused it.
What should we retain for long-term records?
At minimum, a fixed-layout copy of every drawing as issued, and a neutral geometry export of the released models. Generated at release, these are cheap and independent of any application remaining installed or any file format remaining readable.
Retain the native files as well, since they are what makes future modification practical. But treat them as the working copy rather than the record. Where the retention obligation runs to decades, plan for a periodic migration of the native set, or accept that the neutral copies are the enduring record and size them accordingly.
Series context. This page is part of the KEVOS® SOLIDWORKS environment administration series. It presents general administration practice and is written to be release-independent wherever possible. Where specific versions, limits or supported platforms are cited, they reflect the SOLIDWORKS 2026 release family and should be verified against current vendor documentation before being relied upon for procurement, platform or upgrade decisions.
SOLIDWORKS is a registered trademark of Dassault Systèmes SolidWorks Corporation. Product names are used here for identification and reference only. KEVOS® is independent and is not affiliated with, endorsed by, or a reseller for Dassault Systèmes.