MicroStation V8i: will the subfolders in MS_MDL and MS_MDLAPPS paths be searched?

Hi Sui,

it seems to me you asked for the same (or at least very similar) thing already and it was answered.

Sui Huang said:

The observation doesn't seem intuitive to me, so posting this question to confirm.

I think it's perfectly intuitive, but with so long experience, I am not probably right person to evaluate this :-)

But at least, it's perfectly logic and well documented.

Sui Huang said:

Is there any documentation for this?

Yes, in MicroStation V8i, see (and study, because it's crucial knowledge):

• Chapter Setting Up Projects > Workspace > Workspace Fundamentals to understand, how MicroStation is configured through workspace.
• Chapter Setting Up Projects > Workspace > Workspace Configuration to understand, how to create own workspace with custom configuration.
• Chapter Setting Up Projects > Workspace > Workspace Configuration > Primary Search Paths Configuration, where variables like MS_MDL etc. are described.

Sui Huang said:

Does this mean that the search path will cover the subfolders?

No! See how configuration variables are defined and what is their functionality. Typically (maybe all?) variables contains path (folder(s)), define the particular folder, but not subfolders.  But of course it depends on variable, its functionality and how its used by MicroStation.

Sui Huang said:

That means the DLL is

I see two problems here:

• To place own applications (especially when they are bigger than very simple one file tools) to MicroStation folder. Follow Windows best practices and to create own C:\Program Files (x86)\ subfolder, to explicitly tell that it's application, not standard part of MicroStation. Of course you have to extend MS_MDL definition accordingly.
• Do not use subfolders extensively, when it leads to extension of MS_MDL (or any other variable). MicroStation cannot do miracles and to add too many (sub)folders that have to be remembered and searched of course have some overheads.

Sui Huang said:

I found that MicroStation can load this DLL file when it starts.

It seems the functionality of mentioned variables is still not clear enough (or maybe it's not precise enough formulation?):

• MS_MDL defines folder(s), where MDL applications (native C/C++ and obsolete pseudocode) are placed. Where "mdl load" key-in is used, MicroStation uses searches locations defined in this variable (it's correct for native apps, there is another variable for NET apps).
  This variable is the only you typically need to change, when custom application is added to MicroStation.
• MS_MDLAPPS defines, what applications (in what folders) will be visible in MDL dialog in Available Applications list. Personally I treat this variable as obsolete and see no reason to use it. It's mostly historical relic from times, when there were just a few of MDL applications loaded (but today MicroStation itself consists from tens and tens of applications ;-).
• MS_DGNAPPS defines applications explicitly (by name) that are loaded every time a design file is opened. Normal application does not need to be defined here and when this variable is used, it should be done carefully, because it defines extra tasks MicroStation has to do with every opened file.

With regards,

  Jan

Hi Jan, thank you for your detailed explanation.

If possible I would avoid adding sub-folders in MicroStation system path as you suggested, such that I wouldn't be in an edge situation. However, I am trying to learn an existing system, and trying to get more understanding before making any change. The described observations are from part of the system.

This question is different from my previously asked question, because in this question I am trying to find out whether the search would be performed in sub-folder.

Your answer told me two essential points:

1. sub-folder is typically not covered for search paths

2. .NET DLL's search paths is defined by other variable other than MS_MDL

That means my guess to explain the situation was wrong. May I ask this follow up question: which variable is for the search path of .NET DLL files? 

This may help me to explain the observation, but I couldn't find that variable name from the primary search path list.

Thank you!

Sui

Sui Huang said:

However, I am trying to learn an existing syste

As I recommended, study the chapters about workspace system at first. It's absolute mandatory knowledge for MicroStation-based products administration and also for decision how 3rd party applications should be deployed.

To understand a functionality of configuration variables is parallel task, but can be achieved easier with the knowledge how workspaces are created, structured and processed when MicroStation starts.

Sui Huang said:

1. sub-folder is typically not covered for search paths

It's alwyas "per variable" feature. So you have to consult documentation what a particular variable does and how it should be used. Some variables contains numbers, some words, some one folder, some one complete path, some can contain a list of folders.

But until it's stated explicitly, no variable is evaluated recursively.

Sui Huang said:

May I ask this follow up question: which variable is for the search path of .NET DLL files? 

New question, so you should ask in the new post ... or to search MicroStation help or this forum, because it has been discussed many times ;-) But anyway:

• MS_ADDINPATH defines location of NET dlls (applications based on Bentley Addin class). Be aware they cannot be on network drives by default (which is feature of NET 3.5 security system, not MicroStation limitation).
• MS_ADDIN_DEPENDENCYPATH defines supplemental path for dependencies. Typically there is no reason to use it.

Sui Huang said:

but I couldn't find that variable name from the primary search path list.

Both variables are described in Primary Search Path Configuration Variables chapter I mentioned above.

With regards,

  Jan

Hi Jan,

Thank you for your follow up.

I did read through the Workspaces documentation to understand how the configuration of workspace work before posting the question...

The description of MS_MDL in documentation is: "Search path(s) for MDL applications or external programs loaded by MDL applications."

It doesn't mention whether it is recursive or not. Normal if it doesn't mention, I would assume it is not... but as an attempt to explain the observation, I posted this question.

For MS_ADDINPATH and MS_ADDIN_DEPENDENCYPATH, I did see them in documentation and see them pointing to the same location in the system I worked on. However the DLL still loaded after I temporarily delete all DLLs from that location. That's why I assumed there was some other variable and post the question ...

Next time I will separate the questions to different posts.

What was going on is still a little bit of a mystery for me, but at least from you I make sure I generally have some right understanding of how MicroStation works. I will try to figure out from the system later.

Thank you!

Sui

Sui Huang said:

Normal if it doesn't mention, I would assume it is not...

Exactly ;-)

MicroStation documentation (especially V8i, which has long history) is quite engineering, so what is not written, does not exist.

Sui Huang said:

However the DLL still loaded after I temporarily delete all DLLs from that location.

I am not sure whether I understand the described situation correctly. Native apps and managed ones behave slightly different:

• Native application can be unloaded (when the application does not keep some files / resources opened).
• Managed application (C#, VB.NET...) cannot be unloaded ... which is NET feature, because addins are loaded into MicroStation application domain, where they live to the end of MicroStation session.

Sui Huang said:

What was going on is still a little bit of a mystery for me

Well, it's not surprise, because MicroStation is like own OS with workflows based on very long history (imagine tens of years existence, support of many different operating systems including binary compatibility, own language and compiler etc.), so even when now MicroStation is "Windows only", concepts and technologies have remain unchanged ;-)

With regards,

  Jan