ProjectWise CONNECT and MicroStation CONNECT

I have been playing with MicroStation CONNECT and studying ProjectWise CONNECT.

While Bentley has changed names and operability of its MicroStation configuration levels (organization, workspaces, worksets, roles), it appears that Bentley has not made any changes to the managed workspace levels (site, project, discipline, etc.) in ProjectWise .


Is Bentley formally defining any parallels between MicroStation CONNECT configuration levels and the ProjectWise CONNECT managed workspace levels?  Will the managed workspace levels change names or operability in ProjectWise CONNECT in future releases?  Does the MicroStation CONNECT WorkSpaceSetup.cfg file have any impact on ProjectWise managed workspace CSB's?  Will MicroStation users experience anything in the interface that says "WorkSpace" or "WorkSet" when working in the ProjectWise CONNECT environment?



Parents Reply
  • We have gotten managed workspaces to function properly with the loading of the dgnws all in ProjectWise. To do this, we have stood up a CONNECT ProjectWise server to support fully managed workspaces, PWDI 3.49 and MicroStation CE U10. The workset.cfg currently is stored at the root of our active projects/worksets folder and the dgnws is located in the project. We have not taken a second look at relocation if the workset.cfg but at the time we were unable to load it from a different location. The dgnws however has to be created locally and then imported into ProjectWise as it is not branding it to the project when it is created. Bentley has not resolved this issue that I am aware of.

    Setting everything up on our end so far has been quite the challenge as well as a loss of flexibility compared to V8i. But we do have it up and running with the Client workspaces located on the server at the Organization level, and the workset/project loading from inside of ProjectWise. We have bypassed the Workspaces level since it required a much more stringent workspace environment and folder structure. Greg, Bentley sent us an unofficial document on setting up managed configurations with only worksets in ProjectWise. It allowed us to maintain most of our flexibility and folder structure.

    Currently, we have V8i tools and MicroStation CE, AECOsim CE and OpenRoads Designer CE up and running in a managed structure in ProjectWise.

  • We are running into the same issue now at our organization. Is there any official or "unofficial" documentation on how to setup CE projects with worksets to work with ProjectWise?

    OpenBridge Modeler -
    Microstation -

    Comprehensive 3 Day OpenBridge Modeler Training

  • Be sure to read the Limitations section under Before you Begin.  You MUST have your Workspace and Workset cfg files in ProjectWise.  We create a Workset folder under each project to store the matching workset cfg file and the .wsdgn file.  The workset cfg file name should match the Project name assigned in PW as outlined in that document.  The workset file in PW doesn't have set any configs if you're using a CSB to set things.  The file just has to exist for things to work.  We keep our workspace cfg files outside of the project folder structure in a normal folder and that works fine. Just depends on how you're organizing things.

  • Hello Mark, its 2 years I know but just on the off chance - could you please elaborate on dgnws created locally and then imported in PW... I've done all that with ABD update 3 vs PW 280 and still no joy... 

  • As of update 10 or 11 the workspace can be separated from the workset. They must be defined but not longer are required to be in ProjectWise. So we keep the workspaces and the configuration for them on a local server x's offices with a similar mapped drive. The workset configs and dgnws files are stored in PW and are named the same as the PW project. Everything for these items are stored in PW CSB's to allow PW to resolve all paths up front before MicroStation or any Connect application can step in and saturate the environment.

    We set the configuration to the workspace level to the server and not in ProjectWise, then the workset is defined to be in ProjectWise. This ensures that the 2 levels of the Connect configuration that is required is in check, Workspace and Workset. You must define and resolve these. Mandatory for the Connect configuration and very different in limitation compared to V8i. Any failure will result in problems, and more so with any application except MicroStation. Programs such as AECOsim/OpenBuildings fail hard if things are not in check. Another important factor is the workset/project is a ProjectWise project. Something in the folder structure must be a ProjectWise project in order to resolve the workset configuration and use the "$(LastDirPiece(DMS_PROJECT(_DGNDIR)))" variable to find that PW project. it should be defined as:

    _USTN_WORKSETNAME = $(lastdirpiece(dms_project(_dgndir))) 

    It is just how Bentley designed it so we must work within the confines of it. Be sure to define a location for the WORKSETSROOT location as this determines where the workset cfg and dgnws are found. We keep these in a single folder in the hope that Bentley relaxes the configuration requirements for this. But we can also run a query on this to validate that the workset cfg exists. The file can be completely empty but it must exist. Same with the workspaces cfg file.

    We create the workset config file manually (scripted via PW admin and PowerShell) and when MicroStation CE or any Connect application is started for the first time on the project, the configuration in place validates that the workset config is in place and then natively the Connect application checks to see if the dgnws file is in the same place as the workset.cfg, if Yes, then PW pulls it down and uses it, if No, then the Connect application automatically creates it in the dms folder, pushes it into PW, checks it in and then uses it. I have not found a way to create a dgnws and push it into PW outside of this workflow in a seemless process. Seems like the Connect application needs to do all that work.