My .NET AddIn uses a third-party assembly Newtonsoft.Json. If you need to read or write JSON files, it's a very useful addition to your toolkit.
If I build my app as usual, then load and run it in MicroStation, I get an error: 'Cannot load Newtonsoft.Json v12.0.0'. This had me puzzled, because the build copies the assembly to ..\MicroStation\mdlapps along with the AddIn. I spent a day trying to work out whether this was a versioning issue (the version no. in Viz Studio is 12.0.3) with no success. I'm not the only one using Newtonsoft.Json; there's an early version in Microsoft's Windows SDK folder. Eventually I worked out that MicroStation could not find the assembly in ..\MicroStation\mdlapps. I copied the assembly to ..\MicroStation, and now it works.
However, I don't want to pollute the ..\MicroStation folder with assemblies that belong to AddIns. What configuration variable can I use to tell MicroStation to look elsewhere? MS_ADDINPATH and MS_ADDIN_DEPENDENCYPATH look promising. In my current installation of CONNECT Update 14.2, they both point to $(MSDIR)mdlsys\filehandler\RealDwg2019\, even though the comment in MicroStation's configuration dialog tells us that MS_ADDIN_DEPENDENCYPATH should not duplicate MS_ADDINPATH.
What's a good solution?
Hi Jon Summers,
As Joerg correctly notes how to influence .NET behaviors (and should be respected) but there is also (system/software) Consistency and Complexity to add.
Below is a list of variables an application may wish to configure in an Application Config File or otherwise to insert itself functionality across a number of respective API layers/features listed then appended within the MicroStation Environment Variables system and/or process environment block (PEB) layers in the order listed. This slightly annotated list illustrates the DWG API implementation processing layers and order currently used:
Let me know if there is something more needed.
Robert Hook said:Joerg correctly notes how to influence .NET behaviors
Robert Hook said:Below is a list of variables
Thanks for the hints. But my question remains: "How does MicroStation find .NET assemblies?" There's a distinction between an AddIn DLL and a third-party assembly, which is also a DLL...
The results of my own tests, where the configuration variables mentioned above are unchanged from their default values, show that...
I don't want to install third-party assemblies in the MicroStation folder, or the MS_MDLAPPS folder, for a variety of reasons. I'm seeking to install them somewhere where they will not clash with other assemblies of the same name, and where MicroStation can successfully find and load them. One way to achieve that would be to define additional folders, possibly in MS_ADDINPATH or MS_ADDIN_DEPENDENCYPATH.
Does MS_ADDINPATH specify a preferred folder for AddIns? Is their any benefit over installing AddIns in the MS_MDLAPPS folder(s)? Does it instruct MicroStation to search that folder for assemblies?
MS_ADDIN_DEPENDENCYPATH (EC library access) puzzles me. Is that not the right configuration variable to use if we want to instruct MicroStation to search for assemblies? Or, is it in some way restricted to things related to EC libraries?
Regards, Jon Summers LA Solutions
Jon Summers said:Does MS_ADDINPATH specify a preferred folder for AddIns?
I think it's exactly the definition of this variable (from V8i times, has not been changed in CE).
Jon Summers said:I don't want to install third-party assemblies in the MicroStation folder, or the MS_MDLAPPS folder, for a variety of reasons.
Yes, it's the right approach. I think it has been standard solution from V8i times that managed applications are installed in (any) own folder and MS_ADDINPATH is set accordingly. As far as I remember, no other variable has to be configured.
Labyrinth Technology | dev.notes() | cad.point
I reviewed the MicroStation CONNECT (and V8) .NET assembly loader code. It only has interest in user configurable folders specified under MS_ADDINPATH and MS_ADDIN_DEPENDENCYPATH. The "mdl load <appname>" key-in logic does not require a file extension and to blend seamless behavior between interpreted (v8), native, and managed code application loading possibilities each folder is iterated producing a file list against which the requested "name" provided is tested for a suitable matching name.dll or name.exe to then attempt to load as an assembly into our application domain.
So, if you append the install location of your MDL addin folder to (preferred) MS_ADDINPATH, you should be able to load your custom app similar to any other application.
If the trouble is during the load of a "dependent" 3rd party .NET assembly; first confirm those resources are registered in the Global Assembly Cache (GAC) to load by reference, or otherwise confirm they can be located and loaded (Assembly.Load "probing") by: How the Runtime Locates Assemblies.
Let me know if this helps or more information is needed.