Since Update 17.2 was released we has needed a secure method to start MicroStation with a specific Configuration Name, WorkSpace and WorkSet.
Today there's two Command Line Parameters to set the WorkSpace "-wk" and the WorkSet "-ww" but there isn't any for the Configuration Name (Installed Configuration, Custom Configuration and/or ProjectWise Drive) which is stored in the Configuration.xml file.
Therefore we need another parameter eg. "-wm" which controls the Configuration Name.
If we can’t specify the Configuration Name then MicroStation can't nessesarly find the desired WorkSpace/WorkSet if the latest used WorkSpace/WorkSet was chosen from another Configuration Name or path.
The problem is that MicroStation writes the path to _USTN_LAST_ACTIVE_CONFIGURATION into the cache.ucf file and if the last active Configuration isn't in the last "active" Configuration path it can't find the WorkSpace and WorkSet the -wk and -ww parameters is calling for!
Another problem is that if you have used the Examples Configuration MicroStation also changes the third last line inside the ConfigurationSetup.cfg from _USTN_CONFIGURATION = $(_USTN_CUSTOM_CONFIGURATION) to _USTN_CONFIGURATION = $(_USTN_INSTALLED_CONFIGURATION) ...and until you have changed this to Custom the parameters is (again) useless (because MicroStation can’t find the Custom WorkSpaces and WorkSet in the Installed Configuration Path)!
So please gives us a new paramtere fx called -wm to set the name of the Configuration.
In addition to this there’s also a problem controllling the filename and path to the Configuration.xml – please notice Sean Duphilys idea: https://microstation.ideas.aha.io/ideas/MSR-I-1164
Background info
Most of the time we don't use the MicroStation Work Page to choose the desired WorkSpace and WorkSet. Instead we just use a MicroStation shortcut at the desktop or double- (or right)-click at a dgn file. In both cases we have added command line parameter (-wk and -ww) which sets the appropirate WorkSpace and WorkSet. The command line paramters is added in the desktop shortcut or in the WIndows registry key which controls how a dgn files must be opened (under Computer\HKEY_CLASSES_ROOT\Bentley MicroStation Design\Shell).
I agree with previous comment, using metrostation plagues any of your own configurations. A virus, yes thats true. Using the Bentley Institute configuration does a similar thing. Thanks for adding a configuration level to the launch, but you have not provided us with the ability to assign the configuration in a dgn file (that I can see). I have submitted a support call on this and have been waiting a month for a response so I guess its a solid no. The file associateworkset command will write the workspace and workset values, but there is nothing to associate/disassociate the configuration. Please complete the loop on this, and provide useful documentation for workspace administrators to manage this.
please update the "Configuration Explorer" tool to match configurations
This is a great tool, but now, we can not figure out what configuration is used.
This is an important tool to debug custom configurations.
So it is very important to have a working tool.
Yes, we can use the debug output with the -wr -wk -ww parameters to import into the config explorer, but the result is not that much usfull as a processed configuration in the tool itselve.
@Roger Fujan: Thank you very much for your comment - I'm totally aggre: it's a nightmare controlling the ConfigurationSetup.cfg ...in some cases we just change the fileproperties for this file to be readonly!!!.
I didn't know about of the parameter -wr . Is it a undocumented parameter ...or is it just me who can't find anything about it?
I just tested it, but as far as I can tell it only partially works.
It works ok if you just need to open the MicroStation Work Page (and it ignores the path set in the Cache.ucf). In this case I'm able to control which Configuration Path, WorkSpace and WorkSet the Work Page opens with.
But as soon as I'm using the -wr parameter MicroStation also changes/edits the Configuration.xml file: it deletes the Bentley Example Configuration (that's a minor problem) but it also deletes other configuration path's (ProjectWise Drives etc.) and add a new _USTN_USER_CONFIGURATION path ...besides the existing _USTN_CUSTOM_PATH. I don't like this "autoedits" but anyway. I would be able to workaround this.
But the major problem is that we nomally doesn't open the Work Page. We just call a specific dgn file using the command: MicroStation.exe -wr(ConfigurationPath) -wk(WorkSpaceName) -ww(WorkSetName) (path- and dgn-filename)
When I do this MicroStation doesn't open the dgn file with the WorkSpace and WorkSet I have set in the command! ...it actually opens with the WorkSpace and Workset which is assigned (branded) in the dgn file AND MicroStation do this without any WorkSet mismatch alert (and I hasn't any paths defined in the MS_WORKSETMISMATCH_ALERT_EXCLUDE_VARS... variables!).
@Bentley: please dig into this problem so the -wr parameter works properly and without any "auto-change" of the corresponding konfiguration files: Configuration.xml and also ConfigurationSetup.cfg
Do you mean like the -wr(ConfigurationPath) -wk(WorkSpaceName) -ww(WorkSetName) that is already in there? I agree that the software should never change a .cfg file and that _USTN_CONFIGURATION = changing in the configurationsetup.cfg has been a nightmare to manage.
The custom configuration parameter should also be commented out (not set to empty) by default. This would allow you to define the parameter in the command line (or as an environment variable) and not have it set back to empty when it reaches that file
I use the command line switches -wk and -ww all the time. Workspaces is an important mechanism to manage standards and libraries. I recently had issues where the command line switches were rendered useless due to configuration changing as described in this post. I was using the LEARN server installed files and config file, which inadvertently directed MicroStation to look for workspaces elsewhere. Until I removed that configuration file, I was unable to use my own workspaces. While not directly related to this idea, nominating a configuration might resolve my issue also.
I too have wondered about this, and it would be nice to be able to control it as suggested.
Really something we need ASAP!
An additional wish: it might also be a good idea with a start parameter to set the "Role" configuration level
For Bentley: Ive also filed Service Request 7001588188 for the missing/wrong WorkSet mismatch alert when using command line parameters!
Totally agree, we have novice users that occasionally stumble on the "metrostation" example set and it acts as a virus breaking our links to the std config and changing all files to not use the std config. so far our solution has been to delete the metrostation example set. we do not use worksets ever.