• State Verified Answer
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 32 subscribers
  • Views 1989 views
  • Users 0 members are here

[CONNECT .NET] How does MicroStation find assemblies?

Jon Summers
Offline

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?

  • Append ..\MicroStation\mdlapps to MS_ADDIN_DEPENDENCYPATH?
  • Create a new folder for my AddIn beneath ..\MicroStation\mdlapps and point MS_ADDIN_DEPENDENCYPATH at that sub-folder?
  • Something else?
Parents
  • 0 Offline

    Hi ,

    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: 

    • MS_MDL (global MDL access)
    • MS_LIBRARY_PATH (primary native library access)
    • MS_ADDINPATH (.NET addin access)
    • MS_ADD_DEPENDENCYPATH (EC library access)

    Let me know if there is something more needed.

    HTH,
    Bob 



  • 0 Offline in reply to Robert Hook
    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...

    • An AddIn is implemented in a DLL, placed in the ..\MicroStation\mdlapps (MS_MDLAPPS) folder.  MicroStation can find and load the AddIn DLL
    • A third-party assembly is loaded by the AddIn at run-time.  The AddIn is running in MicroStation's address space, and the .NET run-time looks for the third-party DLL in the folder of the owning process

    The results of my own tests, where the configuration variables mentioned above are unchanged from their default values, show that...

    • MicroStation looks for assemblies in its own folder (i.e. where MicroStation.exe is located)
    • MicroStation ignores assemblies in the (MS_MDLAPPS folder

    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

  • 0 Offline in reply to Jon Summers
    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 - Associate
    Labyrinth Technology  |  dev.notes()  |  cad.point

  • 0 Offline in reply to Jon Summers

    Hi ,

    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.

    HTH,
    Bob



Reply
  • 0 Offline in reply to Jon Summers

    Hi ,

    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.

    HTH,
    Bob



Children
No Data
Communities
Support and Services
Training and Learning
Social Media