Enable portable Sheet Set (DST) linking and multi-machine publishing support in Civil 3D

[pedro_blezins]

Problem

When using Civil 3D Sheet Sets (.DST) generated from View Frames, the software stores absolute file paths and static GUIDs inside each layout and view reference.
If the project is moved to another PC or a different user plots the same DST, the link between the layout and the Sheet Set breaks — even if the .dst file is in the same folder and loads correctly.

During publishing, the Sheet Number and Total Sheets fields become unresolved (####), because the publisher engine cannot locate the original SheetSet reference.

This issue is not user-correctable: the link relies on environment-specific GUIDs and paths hardcoded at sheet-creation time.

Impact

This behavior severely affects production workflows for long linear projects such as roads, railways, drainage systems, and pipelines, where hundreds of sheets are created through View Frames.

In real engineering offices, teams often split plotting tasks across multiple machines to reduce publish time (each workstation publishing a segment of the project).
Currently, this is impossible because Sheet Sets are not portable — only the original machine can publish them without breaking field references.

It also blocks collaboration through cloud storage (OneDrive, BIM 360, etc.), where each workstation has a slightly different absolute path.

The result:

Lost productivity and longer publishing times

Inability to parallelize work across machines

Frequent regeneration of entire sheet sets just to restore numbering links

Steps to Reproduce

Create a Sheet Set (.dst) from View Frames in Civil 3D.

Move or open the project on a second PC (different user path, e.g. C:\Users\Pedro\... → C:\Users\Admin\...).

Try to publish the same DST.

Observe that the Sheet Number field displays #### even though the DST loads fine in Sheet Set Manager.

Technical Cause

Sheet and View Frame metadata store absolute paths and non-portable GUIDs.

The Civil 3D Publisher does not rebind these when the DST is opened in a new environment.

The Sheet Set Manager can “see” the DST file, but the Publisher cannot resolve the internal ID linkage.

Proposed Solution

Implement relative path support for DST references (similar to XREF relative paths).
→ Example: use .\Sheets\Project.dst instead of C:\Users\Pedro\...\Project.dst

Add a “Rebind Sheet Set” or “Repair DST Links” command
→ Regenerate SheetSet GUIDs and re-associate layouts when a DST is opened on a new machine.

Update the Publisher engine
→ If the original DST GUID cannot be found, fallback to the active SheetSet context (as loaded in Sheet Set Manager).

Enable shared/multi-machine publishing mode
→ Allow multiple Civil 3D instances to publish subsets of the same DST simultaneously without breaking field resolution.

Benefit

Multi-machine publishing (parallel plotting) for large corridor projects

True portability of Sheet Sets across environments and users

Reduced rework and time loss in collaborative workflows

Improved compatibility with cloud storage (OneDrive, BIM 360, Google Drive)

Example scenario

A 30 km highway project has over 400 plan/profile sheets created via View Frames.
To speed up production, engineers want to split publishing across 4 PCs.
Currently, only the original PC can publish with correct sheet numbering — others show ####.
This forces regeneration of the entire sheet set, wasting hours.

Conclusion

This issue affects every Civil 3D user working on large, collaborative projects.
Allowing relative or portable DST links — or a “Rebind” tool — would dramatically improve real-world productivity and multi-machine workflows.