Hello
As far as I can see Bentley has made some significant changes in msconfig.cfg. Until Update 14 the Configuration levels was included (by cfg files) in the following order:
1. System (Line #133)2. Application (Line #148)3. ConfigurationSetup (Line #243)4. WorkSpaceSetup (Line #268)5. Organization (Line #279)6. User (Line #289)...But Update 15 has this order in msconfig.cfg:1. System (Line #137)2. ConfigurationSetup (Line #255)3. WorkSpaceSetup (Line #280)4. Application (Line #304)5. Organization (Line #314)6. User (Line #338)
Why is it that the Application level now is included after Configuration- and WorkSpaceSetup?? ...and is this an intended and permanent change or something which may change in future updates? I strongly urge Bentley not to make these changes unless it is unavoidable ...and, if so, please write it in the release notes.
The reason why I'm asking is that we have our custom setup and don't want to edit the delivered configuration files. We just add an extra custom.cfg file so it's easy to see whats differs from the original cfg files. One example is that I have added a custom cfg file (Named Zetup_Custom_Config.cfg) in the Application folder. In this file I define _USTN_CUSTOM_CONFIGURATION. By doing so I don't have to edit ConfigurationSetup.cfg and this worked fine until Update 15 (because the Application level was read before ConfigurationSetup!). Using Update 15 I have do something else :-( ...fx. move my custom file to the System folder...?
Best regards
Anders
Hi Anders,
The msconfig.cfg changes are in preparation for the later addition of some optional configuration that will make it easier to integrate different applications within one Custom Configuration.
We continue to recommend that CFG files in the "C:\Program Files\Bentley\...\config" folders are not modified and that all configuration is implemented from ConfigurationSet.cfg and above.
Your point about highlighting this in the release/what's new information is valid and noted.
Marc
Hi Marc
Thanks for your answer.
I’m happy to read that you’re now is working towards a “cross-application” configuration. You may remember we had a mail conversation about this back in 2018 (since 2017 we have managed to create and use a common setup for MicroStation, OpenRoads Designer and also OpenCities Map incl. our own developed applications).
I also don’t wanna edit the delivered configurationfiles. Therefore I’m planning to create a “Zetup_MyConfigurationSetup.cfg” file and copy it into the folder $(MSLOCAL)Config/System. The filename begins with an “Z” because I need it to be the last thing to be read in the “System” folder, just before ConfigurationSetup.cfg will be included (I don't wanna mess anything up!). In the Zetup-file I define _USTN_CUSTOM_CONFIGURATION
Another thingWhen the installer creates the ConfigurationSetup file it creates (among other things) this line in the ConfigurationSetup.cfg file:_USTN_CONFIGURATION = $(_USTN_CUSTOM_CONFIGURATION) But as MicroStation starts up it usually automatically edit this line and exchange the variable (_USTN_CUSTOM_CONFIGURATION) with a hard-coded file path instead of a variable???
Why this ”hardcoded path”? The reason why I’m asking is that we sometimes use another path to the Configuration folder and therefore redefines _USTN_CUSTOM_CONFIGURATION (normally the Configuration folders is at the server but sometimes we running locally on the C-drive. The first time after we redefine _USTN_CUSTOM_CONFIGURATION MicroStation hasn't yet updated the "hardcoded" patch and therefore we have to manually choose WorkSpace and WorkSets. Next time we starts MicroStation the hardcoded path is updated and then it works fine until next time we change.
Regards
I filed Defect 1037427: 'Application write operations to Line 26 of ConfigurationSetup.cfg should insert configuration variables not hard-coded paths' about this a while ago, please file a service request referencing this defect number to add your voice to those requesting this change.
Marc Thomas said: ConfigurationSetup.cfg should insert configuration variables not hard-coded paths
Thank you ...that's great news. I'll file a service request and add my comments.
Anders W said:Therefore I’m planning to create a “Zetup_MyConfigurationSetup.cfg” file and copy it into the folder $(MSLOCAL)Config/System. The filename begins with an “Z” because I need it to be the last thing to be read in the “System” folder, just before ConfigurationSetup.cfg will be included (I don't wanna mess anything up!). In the Zetup-file I define _USTN_CUSTOM_CONFIGURATION
Since you haven't made a comment to this I'll guess it isn't totally foolish ;-)
Hi Anders, you clearly know what you are doing and what you wish to achieve and have a plan; as the file is read last it should not interfere with the configuration file sequence, look forward to hearing that it works :-)