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.
..\MicroStation\mdlapps
..\MicroStation
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.
MS_ADDINPATH
MS_ADDIN_DEPENDENCYPATH
$(MSDIR)mdlsys\filehandler\RealDwg2019\
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.
HTH,Bob
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...
MS_MDLAPPS
The results of my own tests, where the configuration variables mentioned above are unchanged from their default values, show that...
MicroStation.exe
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 there 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.
Regards,
Jan
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point