I'm in the process of implementing changes to our companys workspace to get Connect Edition running.
We have previously had a very simple method of running Aecosim V8i, the only thing we did was setting a Windows System Variable (_USTN_WORKSPACEROOT) to the network folder where the workspace was, and everything was running nicely.
This isn't working anymore,as _USTN_WORKSPACEROOT is not the same anymore.
First thing therefore was undefining this Windows System variable, and instead running V8i with command line switch "-wrM:\Microstation\Workspace\".
V8i still working the same way as before, which is a nice thing.
My question now is, can I do the same thing with Connect Edition?
The purpose would be the same, the program shouldn't look for the 2 configuration files ConfigurationSetup.cfg and WorkSpaceSetup.cfg on a local drive, but on the network.
Andreas Zieritz said:ConfigurationSetup.cfg seems to be dynamic. I haven't read about that before, but your last reply specificly says so.This is the first time I have experienced that from Bentley. Just wonder what happens if you open 2 files from different workspaces / worksets...
The instance that was opened first would continue to operate with the variables, etc. as set by the WorkSpace/WorkSet selection when the file was opened.
The last instance to close would be the last to write to ConfigurationSetup.cfg.
However, you only have one Configuration location: M:/Microstation/Workspace_Connect/Configuration/ so the configuration statements would not be changed unless the second user switched to the Example project on the C:\drive.
If you check (when ABD is closed!) that your ConfigurationSetup.cfg contains the text listed above, when you open the ABD it will open in the Examples. Change the WorkSpace to your own, open a file then close ABD and see what has been written to ConfigurationSetup.cfg.
Andreas Zieritz said:WorkSpaceSetup.cfg apparently must be on the local drive, and not on the network drive.Just to make sure that I didn't screw the configuration, here are the active contents from my local WorkSpaceSetup.cfgMY_ORGANIZATION_LOCATION = M:/Microstation/Workspace_Connect/Organization/MY_WORKSPACES_LOCATION = M:/Microstation/Workspace_Connect/WorkSpaces/
ConfigurationSetup.cfg will direct MicroStation or ABD to the network. Unless you want to change the name and/or location of the Organization and/or WorkSpaces folders you can leave WorkSpaceSetup.cfg in its delivered state with everything commented out.
(I've asked development if we really need to have the options offered here in a separate file or if we can roll them into the Standards.cfg to simplify things a little.)
Making progress now.
The first thing - I had a typo in my configuration file yesterday, which was one reason that it didn't work (_USTN_CUSTOM_CONFIGURATION did point to a non exisiting folder).
If there is one thing which you could do, is to add a note in ConfigurationSetup.cfg.
My proposal (please change to more correct english):
# The contents of section below MUST not be changed, as the are changed by the program after each program close![SetConfiguration]
In addition, you could also have a note in WorkSpaceSetup.cfg, that this file can be moved to a network drive. And that ConfigurationSetup.cfg must be on the local drive, and not on the network drive.
Great. Good suggestion regarding notes in the file. I will follow that up. I'm proposing similarly helpful notes in some of our other files.
Is there any equivalent of the -wr command line parameter in Connect? Reason for asking is that I want to create the same network configuration as Andreas. But using your suggestion Marc, the system administrator has to make changes in the default installation of MicroStation/Aecosim on every update or reinstallation or on every local system. As many of them are working with VDI's or images, they have to be aware of the change of directory during installation. And when changing the network location of the MicroStation/Aecosim configuration they have break open the VDI image and rebuild it. Quite a lot of work for the system administrators, where using the command line parameter -wr (or its equivalent for CE) require just a 'next, next, next, finish' installation and adding a simpel shortcut to the user's environment. A two minute job instead of rebuilding the complete image.