[MS CONNECT U14] Multiple Worksets read on startup

Hi Stephan,

Stephan L. said:

or give me a hint into the right direction to fix this?

When workspace configuration is analyzed, to create complete (the most detailed) msdebug file has always to be the first step. Without this file available, no further discussion is possible.

Stephan L. said:

That makes me think that not only Workspace A and Workset3.cfg is read (multiple times) when starting Microstation

And what? Is there specified anywhere that a configuration file is read once only? To build the whole configuration is pretty complex process, so probably some files have to be read several times.

With regards,

  Jan

Hi Jan,

I did create a msdebug file and there was no sign of Microstation reading other workset cfg files than the active/selected workset. Maybe I have to take a closer look at the msdebug file but I'm pretty sure that I already did. Most detailed? I don't know. I just use -debug. Maybe I have to add a number like -debug=5? I thought that this is default.

Of course Microstation can read the config files as often as it wants to and as often as it needs to. But only as long as it is the selected/active workset cfg, please. Not some "random" other Workset cfg file. But thinking about it I realize that I thought "processing == reading/loading". That is propably not true. Nonetheless it came by surprise to see that message multiple times. Would you have expected that behaviour?

Problem is that not all users have access to all project directories. There was the rare case that inside the Workset cfg file I wanted to include some extra cfg file that belongs to the project and therefore is saved inside that project directory. Now when a user starts Microstation with selected Workset 1 and by accident Workset2.cfg is read (with an %include to some cfg file inside project directory) the user will get an error message depending on whether he has access to that directory or not.

This error message would be fine if the user had choosen a project where he has no permission to work on. But if the user selects his own project and gets this message this is not the way I would like to have it.

I guess I have to do some more testing until I find the mistake that maybe I did. Before spending hours on debugging the configuration I just wanted to check with you guys whether this has happened to anybody else.

The configuration is pretty new so I guess that initial difficulties are to be expected.

Hi Stephan,

Stephan L. said:

but I'm pretty sure that I already did.

Maybe you did, but you have not shared it, so nobody else knows how your workspace is configured. It's hard to provide any guess in such situation.

Stephan L. said:

Maybe I have to add a number like -debug=5? I thought that this is default.

It's explicitly mentioned in documentation that default value is 4 (I think it was 3 in the past). There is no big difference between 4 and 5, but final summary of variables provided in 5 makes analysis simpler a bit.

i agree it does not provide any hint about the discussed issue, but at least it help to understand your configuration.

Stephan L. said:

Nonetheless it came by surprise to see that message multiple times. Would you have expected that behaviour?

I did not expect it, because I did not do such analysis in the past, but I am not surprised.

It's an internal implementation aspect how the files are processed and how many times. As long as it follows specifications defined in documentation, it probably cannot be treated as a bug. Any variable can be evaluated many times and I can imagine (even when I do not see any obvious reason for that) that in such case the file is processed again.

I did quick test and for the simplest scenario (one workspace with one workset), the workset cfg file is read 3x before start page is displayed and 4x in total when the file is opened.

In my opinion when you are interested in why and under what conditions a file is processed repeatedly, you should split the discussion (ask in a new post for this specific question), because it's not related to bigger issue, which is reading another workset cfg.

Stephan L. said:

I just wanted to check with you guys whether this has happened to anybody else.

I do not recall any such discussion. But I do not think you did anything wrong, so congratulations, you are the first you discovered this (probably) bug! :-)

Stephan L. said:

there was no sign of Microstation reading other workset cfg files than the active/selected workset.

Well, it is a surprise, for sure.

I did quick test (well, not so quick, at the end it required substantial amount of time ;-) and I see an obvious rule ... at least on my configuration: The incorrectly accessed workset file belongs to the first workset in the worksets list, not any other. The first means "alphabetically first".

It seems to be more code bug, not MicroStation or your configuration issue: Probably when the list is constructed, once the first item is used to read some cfg file. For sure it's not correct.

Maybe it's a conflict between code and how MicroStation configuration is defined step by step in many cfg files. When the first workset cfg file is not accessible (e.g. because of access rights), error is reported for this definition in msconfig.cfg:

%if exists ($(_USTN_WORKSETCFG))
%  include $(_USTN_WORKSETCFG) level WorkSet
%endif

What I see in msdebug file, _USTN_WORKSETCFG variable is for long time defined in a bit strange way:

_USTN_WORKSETCFG=$(_USTN_WORKSETSROOT)$(_USTN_WORKSETNAME).cfg
[C:\ProgramData\Bentley\MicroStation CONNECT Edition\Configuration\WorkSpaces\WorkSets\.cfg]

... so it points to not existing folder and file.

It's definitely issue that has to be analyzed with MicroStation code knowledge. I recommend to create Service Ticket and to link also this discussion.

With regards,

  Jan

Hello Jan,

thank you for your reply. I have created a service ticket for this one and hope to get an answer from Bentley. If so I will post it here.

Thank you for the hint that always the first file is read. So now I've created a 0000_Dummy which has not much in it and hope this will help as a workaround.

I have created the msdebug.txt with -debug=5. I think that I rather not want to post it in public but if you are interested in I could send it to you. Though I hope that the workaround will help for now...so maybe we should wait what Bentley will come up with.

Best regards
Stephan

Stephan L. said:

So now I've created a 0000_Dummy which has not much in it and hope this will help as a workaround.

Cool :-)

Stephan L. said:

I think that I rather not want to post it in public

I think there is nothing very sensitive in msdebug file and you can find plenty of them attached for analysis by other community members.

Stephan L. said:

so maybe we should wait what Bentley will come up with.

An aim is Defect number to be created, so the fix can be scheduled and tracked when it will become part of some released version.

With regards,

  Jan

Thanks Stephan,

I am able to reproduce this issue on my side. Created defect for the same.

Defect 1099093*:Multiple and multiple times worksets get reads during MSTN Launch.

Thanks

~ASN

Thanks Stephan,

I am able to reproduce this issue on my side. Created defect for the same.

Defect 1099093*:Multiple and multiple times worksets get reads during MSTN Launch.

Thanks

~ASN