Jump Kit

The Framework for Civil 3D
Get More

Templates Only

See The Framework Work
Get More

Become a Member

Master Civil 3D
Get More

Autodesk Civil Videos

Free Civil 3D Training
Get More

Framework Videos

Free Civil 3D Videos
Get More

Sometimes a broken Reference problem in Civil 3D will stare us right in the face and we still miss and/or cannot find and/or see the reason why. Been there. Done that. Got my T shirt. How can this be? Out here in Civil 3D Land every day we use this vital and basic file Reference stuff like our lives depend on it.

If you tell me that the broken Reference never happens to you, then the odds are you don’t regularly employ file References in your Civil 3D projects. That itself might be a concern. Odds are you waste production time and energy. Your quality control processes would also concern me too. Just sayin’.

The resolution of File Reference issues are also a significant challenge to Autodesk’s march to the production Clouds. Thankfully, Autodesk has been forced to get their act together to make their own production Cloud environments work in the real world with real projects.

The vendor effort has been generally pretty good news for the rest of us. We’ve all been forced to learn how to address the broken file Reference issues in Civil 3D for much longer in our production network environments. Can I hear an Amen?

Excuse me while we take a short but instructive detour into the history of file references in AutoCAD.

Back to AutoCAD References

It’s true that some of us are old enough to remember an AutoCAD that didn’t allow us to employ the External Reference (XREF) and/or the Image Reference (IREF). Funny. At the time we didn’t call this time period the Dark Ages. Those days were a time of technological innovation. Eheh.

Back in the day that release of AutoCAD was the first and perhaps the only release of AutoCAD that many production folks chose to immediately employ even the beta for daily work.
The introduction of the XREF in AutoCAD was that big a deal.
Do you remember the AutoCAD release? Careful. This is a trick question. For those that know we must remember that we must be specific about the version of the release. Hint. It was the extended memory in DOS thing. Eheh.

The introduction of the file Reference in AutoCAD was a big deal.

We went from Drawing Management (a day dominated by the Layer Manager and single users) to Project Management (a day dominated by Reference file structures and multiple users) basically overnight.

People and firms that struggle with the differences and specifics go the way of all flesh.

Tables of References

Autodesk chose to store the file Reference details in a Table inside of the drawing file (.dwg) database. A quick reality check to note here. AutoCAD is a database that resolves pictures (these days we say “models”). AutoCAD is not a software application that draws pictures.

To employ an internal Table to store the file Reference information made a lot of sense. AutoCAD already stored other drawing file data inside an existing Blocks table in every ACAD dwg. This is mission critical tech. An AutoCAD block is an internal Reference that can create instances of that block at various locations and scales.

Autodesk’s concept was that an external Reference would do the same thing as an internal Block reference replacing the internal dwg definition with the entire contents of a separate dwg.
Sounds simple, but it is not really all that simple in its practical daily application(s) as we all know all too well.

For example: Which Layer property definition details does AutoCAD honor? The Layer names and properties in the XREF or the ones in the current drawing?

Attachments and Overlays

Every AutoCAD dwg database is based on an array of internal Tables (Layers, Blocks, Texstyles, Linetypes, etc). Each of these AutoCAD tables (or Styles) has their own set of record property definitions. An AutoCAD that can employ an XREF, or other file reference, must have resolution rules.

Those resolution mechanics quickly get a bit more interesting if we want to consider: a file Reference with its own XREF, or perhaps with a block definition in the XREF that includes yet another XREF, etc.
Out here we all know about nested XREFs and circular XREFs.

Our postmodern Attachments follow Alice down the rabbit hole and our deconstructed Overlays do not.

Inside the classic Reference Table AutoCAD must keep track of that Attach type property, the name of the file, the path to the file, whether the path is Relative or Absolute, and all those other previously mentioned insertion properties needed to resolve the instance of the external drawing file reference.
Pretty simple.

The common problem is we humans can be simple minded. Can I say it? Forgetful.

The What Where and When of My Drawing

The most common problematic file Reference (or XREF) issue is this the simple fact that Dick or Jane (you know that unmentionable person in the cubie next door who often looks and behaves exactly like us) can randomly move or rename a file without notice to anyone else.
It is their drawing after all.

My best buddy Dave – our PM – he loves to delete files, and sometimes entire folders, to keep our Civil 3D projects clean and understandable to him.

“Dave?"
"Dave’s not here."
"Good. Now we can restore that backup from God knows when.”

Trust me. I am laughing and crying with you. This scenario is a big part of the reason why I often rant about the worth and/or need for structured and maintained Civil 3D Project Templates.

See the A Civil 3D Managed Dynamic Model Works blog post. Visit the Project Start up series of posts with videos here.

How Many File References are Out There?

Just how many kinds of external file References do current versions of Autodesk Civil 3D allow for?
It is a big list.

We got our XREFs (dwg references), IREFs (images), DREFs (Civil 3D data references), and TREFs (Civil 3D template references which externalize Civil 3D Style definitions).

Not all of these reference types employ the external Reference Table mentioned above. However, they all employ similar internal Table resources to track, find, and resolve them.

A number of important Civil 3D specific Objects (those things in the Civil 3D Toolspace) can contain data structures that also may reference external files. Surfaces, Survey Dbs, and Points come to mind.

Note that these data source file references like Reference Templates (TREFs) do not yet support a Relative path property. The “yet” here may be wishful thinking.

The Power of Names

The mission critical data in all these external file References are the name of and path to properties of the external file.

It is that pesky Power of Names thang.

What we name it in Civil 3D always matters.

The Power of Names statement is a shout out to the power or problem of our standardized naming conventions, structured projects, and even the regular and thoughtful use of name templates in Civil 3D.

Perhaps we notice that there seem to be more and more rename chores to get and keep straight as our Civil 3D projects get bigger and become more mature.
Probably mature is the wrong word. But you catch the drift.

Faster DWF Publication

DWFs are great for faster publication of complex files like Plan and Profile Sheets because they are actual vector prints of what is resolved in Civil 3D. Think of a DWF as a preprinted resource and the performance benefits should make sense. See this golden oldie blog post and video.

A DWF image does not require anything close to the processing resources and time as a typical XREF basemap or even the smaller resource requirements of the resolution of Styled DREFs in a Civil 3D production drawing.

A DWF file Reference (this is technically an IREF) may contain one or more multiple vector prints. We can even preprint at different scales or rotational versions and store them in the same source DWF.
See the links to the blog posts and videos above or below .

Allow Us to Help You with That

To smooth out customer complaints and make the software easier for users Autodesk often tries to automate the name creation processes in commands, wizards, etc. Makes sense.

Autodesk has a default name convention for the names of the separate child DWFs stored in the parent DWF document.

The DWF and the AutoCAD Sheet Set Manager arose about the same time and for the same basic publication reasons. Child DWF images are automatically named with the source drawing name and the current Layout name by default.

For example - as we bang away we might get “My Drawing Layout 1” as a published DWF image name. Note that this name is a combination of two names for two very different things in AutoCAD.

In context the default combo name sort of makes some sense. However, the folks we know love to create nonsense, don’t they?

DWF Name Defaults

Both of the name of the Drawing and the name of the Layout can be renamed themselves.

It is probably a safe bet that our real-world production drawing gets renamed and perhaps even moved elsewhere in the project. The Layout 1 name sooner or later gets renamed to Sheet 1 or something else that makes more sense at that time to Dick or Jane.

If we are already employed the DWF and the child DWF image as a file Reference in another drawing and Sheet in a deliverables Sheet Set, a failure to properly correct the entire name(s) manually can lead to a pretty interesting broken file Reference.

This DWF broken file Reference is pretty unique in AutoCAD. The only way to update this is to update the name property in the DWF’s list view to the current detail specifics.

Often it is easier to just republish a new DWF with names that more meaningfully addresses the purpose of the DWF image.

Name It to Identify and Produce It

What if the DWFs are generated from modelspace? The default Layout name is Model. What if each of the DWFs is generated at a different scale or rotation? The default AutoCAD-based naming convention for the DWF command doesn’t cut it.

We can forgive the Autodesk programmers for their default names.

We tend to recommend a DWF naming convention based on the output Scale, perhaps a rotation, and some other part of the name based on the AutoCAD named View employed to generate the DWF. For example if we are using the Plan Production Tools we can employ the ViewFrame names and create the AutoCAD Views so we can restore them.

This DWF image file Reference naming convention makes more production deliverables sense. It allows us to go back and reproduce and update the DWF image.

Broken file References happen again and again.

Those Important Broken Reference Tools

We should take a moment and cover the improved tools that help us find and fix them.

All AutoCAD based products ship with the classic Reference Manager tool. The Reference Manager identifies missing file Reference of most types. It will also help us identify those other common missing resources like fonts and STB and CTB files.

Another very important Reference discovery tool is not yet included inside Civil 3D…There that “yet” again. Eheh.

The Reference Explorer that is included with the Autodesk Desktop Connector install is a most excellent tool for discovering where our Civil 3D projects have broken references and lost paths.

We can think of the Reference Explorer as a visual version of the older Reference Manager with the additional important support for Civil 3D Data Shortcuts.
See The Data Shortcut Manager and DREF Replacement blog post for a video and details.

Speaking of Data Shortcuts… the Civil 3D Data Shortcut Manager (DSM) is a vital tool we all need to open frequently. Every Civil 3D user needs to thoroughly understand the DSM mechanics.
See the Civil 3D Reference Replacement and Tools blog post for a video and details.

Make Civil 3D Work Better
Get the Framework for Civil 3D