Where to set the _USTN_WORKSETDGNWSTEMPLATE variable so it's not overwritten by the msconfig file

Hi Ryan, please let us know if this adds any useful info for you: CONNECT Edition - Configuration Tips : Where should I keep my DGNWS files?

No Marc. That info doesn't really pertain to what I was wanting to do. 

OK, thinking back I now recall trying DGNWS variables in a WorkSpace config and it not working. Locating them there was not critical to the examples that I was working on and I arrived at the WorkSpaceSetup.cfg as the best place to locate them without resorting to locking the variables (in my context at least). Typically:

# locate DGNWS in WorkSet Standards folder
_USTN_WORKSETSDGNWSROOT = $(_USTN_WORKSETROOT)Standards/
_USTN_WORKSETDGNWS = $(_USTN_WORKSETSDGNWSROOT)$(_USTN_WORKSETNAME).DGNWS

Using _USTN_WORKSETSDGNWSROOT gave the most reliable results. For more complex scenarios %if logic can be used in WorkSpaceSetup.cfg.

For my situation I wanted to be able to point to a different DGNWS template file that has a set of custom properties in it so I could use it to replace some older project DGNWS files that are missing those properties. Since those projects aren't using the index I didn't loose anything by deleting them and letting ORD regenerate from the template. 

By setting it at the workspace level I can have different DGNWS files with different properties or index folders for different clients if I ever want to delete a DGNWS and let it regenerate. It will also now pick the DGNWS I want for that client without having to pick a project template, but that wasn't really my goal.  

It seems odd that ORD first generates the variable in the msconfig file then will change it at the Organization, Workspace, or Workset level if set, but then looks back at lines later in the msconfig file and changes it right back to where it started . That makes setting it at any other level useless unless it's locked. I guess I don't get why the msconfig file is being looked at twice. Seems it should do what it needs to at the beginning then be done so it doesn't then overwrite changes made at other levels. 

For my situation I wanted to be able to point to a different DGNWS template file that has a set of custom properties in it so I could use it to replace some older project DGNWS files that are missing those properties. Since those projects aren't using the index I didn't loose anything by deleting them and letting ORD regenerate from the template. 

By setting it at the workspace level I can have different DGNWS files with different properties or index folders for different clients if I ever want to delete a DGNWS and let it regenerate. It will also now pick the DGNWS I want for that client without having to pick a project template, but that wasn't really my goal.  

It seems odd that ORD first generates the variable in the msconfig file then will change it at the Organization, Workspace, or Workset level if set, but then looks back at lines later in the msconfig file and changes it right back to where it started . That makes setting it at any other level useless unless it's locked. I guess I don't get why the msconfig file is being looked at twice. Seems it should do what it needs to at the beginning then be done so it doesn't then overwrite changes made at other levels. 

the current msconfig drives me bonkers for overwriting or adding paths after they've been set (msdirs.cfg in the System folder also does a lot of this).

Pretty much my rule of thumb is: if I set a _USTN variable, lock it. It fixes a lot of this.

In MicroStation 17.2 we have updated msconfig.cfg as follows replacing = with :

% if exists ($(_USTN_WORKSPACESROOT)Template/WorkSetTemplate.dgnws)
_USTN_WORKSETDGNWSTEMPLATE : $(_USTN_WORKSPACESROOT)Template/WorkSetTemplate.dgnws
% else
_USTN_WORKSETDGNWSTEMPLATE : $(_USTN_INSTALLED_CONFIGURATION)WorkSpaces/Template/WorkSetTemplate.dgnws
% endif

This will appear in future releases of MicroStation and Open applications.