An out of the box installation of a CONNECT Edition application is largely centered on folders in Windows' default ProgramData folder. This has to be done so the application can be successfully installed in a fully functioning state. However, live operational data is in practice almost always located on network shares for security and sharing.
The location of shared network resources in the Custom Configuration is discussed elsewhere, including in other "Custom Configuration" items in this blog.
Our example configurations generally include the WorkSets that contain project design data, e.g. the primary DGN files within the Custom Configuration. Obviously this is not an appropriate arrangement in practice.
In addition to maintain organizational standards it is desirable to separate live project data folders that are accessible to all project staff from the standards resources and configuration files that should be managed by organization or project administrators. For instance, a project CAD Coordinator in the case of project specific resources such as cell or level libraries.
This separation is actually quite simple to achieve in CONNECT Edition.
A set of Bentley WorkSets are contained within the location defined by _USTN_WORKSETSROOT (the plural…), this is always a WorkSpace. Each WorkSet contains everything that relates to it including the two crucial files that can upset the smooth running of a project if they are lost or damaged.
Project resources and design data are stored in the sub-folders of each WorkSet folder. The location of this folder and its contents are defined by _USTN_WORKSETROOT (the singular…).
_USTN_WORKSETROOT can be defined to point to a separate share or drive mapping keeping the live data project user totally separate from organization standards.
Each WorkSet contains its own set of Standards sub-folders so a project team can add or edit project resources, adding project cells for instance without needing additional access/permissions.
It could be defined in each WorkSet.cfg but that could require each WorkSet.cfg file to be edited.
With a consistent naming strategy it could be defined once in each WorkSpace.cfg. This is the most appropriate level.
Note in this screengrab that WorkSet_01 and WorkSet_02 have .CFG, .DGNWS and their data folders all contained within …\WorkSpaces\WorkSpace_01\WorkSets.
WorkSet_03 only has the .CFG and .DGNWS files.
That is because WorkSet_03.cfg contains the line:
_USTN_WORKSETROOT = //server/ProjectData/Project_03/$(_USTN_WORKSETNAME)/
This relocates the data folders to \\server\ProjectData\Project_03\WorkSet_03
Exactly how these data folders are structured and named can be configured, preferably at the WorkSpace level for consistency across projects. In this example the Bentley defaults are used.
Note: default structures could be applied at the organization level but that would be relatively inflexible. Setting them at WorkSpace level makes it easy to:
When _USTN_WORKSETROOT is defined as shown above, to separate design data from project resources, if you wish (as we would recommend) to keep the DGNWS file located alongside the WorkSet.cfg, ensure that the variable _USTN_WORKSETDGNWS is defined as (note this uses ...WORKSETS...):
_USTN_WORKSETDGNWS = $(_USTN_WORKSETSROOT)$(_USTN_WORKSETNAME).DGNWS
Like _USTN_WORKSETROOT, this can also be defined at WorkSpace level to be consistent across all WorkSets.
NOTE: Currently this arrangement is not fully supported by the WorkSet Creation UI. If the WorkSet_03 in the above example is used as a Template WorkSet the WorkSet.cfg is created in the expected location but the WorkSet folders are not. We are investigating this and will update this article once we have new information.