Changes in ..\apps\PW.cfg between Ss2 and Ss4 causing workspace issues.

We don't have Power InRoads SS2 but we do have MicroStation SS4 + InRoads SS2 and Power InRoads SS10 on a testing machine on it. ProjectWise 10.00.03.329 installed.

The PW.cfg between the 2 is identical, however neither loads the mcm.user.cfg directly. Instead they both load the same mcm.cfg in the Program Files\Bentley\ProjectWise\Bin directory then that mcm.cfg loads the mcm.user.cfg. Actually it'll load 3 different mcm.user.cfg if it can find them.

Here's how mcm.cfg loads the different mcm.user.cfg files:

%include $(PWDIR)bin/mcm.user.cfg

%if exists ($(ALLUSERSPROFILE)/Bentley/ProjectWise/Configuration/mcm.user.cfg)
  %include $(ALLUSERSPROFILE)/Bentley/ProjectWise/Configuration/mcm.user.cfg
%else
  PW_ALLAPPDATA=${ALLUSERSPROFILE}/Application Data
  %if exists ($(PW_ALLAPPDATA)/Bentley/ProjectWise/Configuration/mcm.user.cfg)
    %include $(PW_ALLAPPDATA)/Bentley/ProjectWise/Configuration/mcm.user.cfg
  %endif
  %undef PW_ALLAPPDATA
%endif

%if exists ($(LOCALAPPDATA)/Bentley/ProjectWise/Configuration/mcm.user.cfg)
  %include $(LOCALAPPDATA)/Bentley/ProjectWise/Configuration/mcm.user.cfg
%else
    %if exists ($(APPDATA)/Bentley/ProjectWise/Configuration/mcm.user.cfg)
        %include $(APPDATA)/Bentley/ProjectWise/Configuration/mcm.user.cfg
    %endif
%endif

%endif

Couple of possibilities pop to mind:

1. The Power InROADS SS2 PW.cfg is old and the installer didn't support that version so didn't replace it
2. Both Power SS2 and SS10 pw.cfgs were manually modified and at the last install of PW weren't replaced by the installer
   1. Bentley ProjectWise installers tend to leave manually modified files in place and not replace them when a new version is installed

Shouldn't have to do a complete uninstall/reinstall. Honestly just replace the pw.cfg in both with the one from Program Files (x86)\ProjectWise\Bin. That file is the only thing that integrates MicroStation based products with ProjectWise. Replacing it with the one from the program directory is pretty much what uninstall/reinstall is supposed to do.

This is my Power InRoads Ss2 PW.cfg. The %if %endif block from lines 38 to 45 fail in Ss2. The lines 44 through 47 in the Ss10 version (see further down) are the lines that will not fail, if I use the Ss10 version in Ss2.

While this is my Ss10 version

The Accessed date on both matches the date that I installed Power InRoads Ss10 and I believe I ran a repair on ProjectWise, since it was installed while Ss4 was installed.

Hi Chuck,

From my testing registryread is not recognized in earlier versions of the software (before connect, although I haven't tested Ss10) and was only recently added to the list of commands that cfg files could handle.
AFAIK, the PWDIR variable is typically passed from the ProjectWise application on launch so would only be used if not launching from the explorer window. See below image

If I put the Ss10 version on my PC, it works, but modifying file in the Program Files (x86) area is the one thing we are trying to avoid.

And yes, within PW, it does work, but we were trying to place some site variables in one place that any Bentley software integrated with PW would read. This allows one location that everything through CONNECT will see.

This will go away once Ss2 doesn't run, but it's annoying that something that could (or should) be universal is not.

Remember, the goal is to not need admin privileges to configure the workspace, in or out of PW.

is there a particular reason you want these settings on the local machine at all? We put all our projectwise settings in our site config on our server and just load it as part of the standard workspace. If a particular project or user needs a different setting we would put it in the project config or the user config.

Chuck,

Good to know that Ss10 works with registryread. I guess that's one change that makes the earlier versions incompatible with newer connect editions of PW explorer. As a test you could try install the V8i version of the explorer to see what the pw.cfg files settings look like. I'd be surprised if it contained the registryread command, but it may give you an insight into a potential solution.

Regarding having the workspace configurable without admin privileges, we use the managed workspace only to determine the locations of config files that are located in PW folders and then "%include" those cfg files as part of the workspace. These can be set as editable by non-admin staff.

We are trying to simplify workspace setup for our consultants - many use our workspace for other clients which we like to encourage as it makes them more efficient when working for us. And not all of our offices require the use of ProjectWise.  Many of our consultants struggle with multiple workspaces so we are working to make it easier for them. 

We are trying to simplify workspace setup for our consultants - many use our workspace for other clients which we like to encourage as it makes them more efficient when working for us. And not all of our offices require the use of ProjectWise.  Many of our consultants struggle with multiple workspaces so we are working to make it easier for them.