This a quite a bit strange topic, I built an addins and ran well with Microstation V8i SS3/SS4. One day, I found that the same addins which is not able to be loaded in Microstation SS10, with a message shown: "MDL Loader: Could not Load Application D:\XXX.dll". Are there any ways to fix it? Or shows what's wrong while loading the addins?
Hi,
clever_anthony said:Or shows what's wrong while loading the addins?
Usually there is no detail information, when NET addin loading process fails, so it's hard to decide whether it's caused by addin itself, MicroStation or NET Framework.
clever_anthony said:Are there any ways to fix it?
There should be the way, but at first you must find the reason of the discussed problem.
You do not share too many details about the application, so it's not clear whether it's one .dll (plus .ma loader) or there are more dlls files. Also crucial is to know whether applicaiton is loaded from local folder or from network drive.
What you should check:
Because the application worked fine in the past, I assume everything was set correctly and nothing changed (e.g. workspace was not modified by somebody else).
You should be aware loading NET assemblies is controled by security system, and loaded dll files must be in "trusted zone". In NET Framework 3.5, local folders are trusted automatically (when not changed by e.g. domain rules). But it is something than can be changed by Windows or domain admins, so e.g. caspol.exe (Code Access Security Policy Tool) should be used to check the addin location is still trusted.
With regards,
Jan
Bentley Accredited Developer: iTwin Platform - AssociateLabyrinth Technology | dev.notes() | cad.point
Answer Verified By: clever_anthony
Not sure if this might help but i ran into it on some of my VBA programs if you are on a 64 bit platform and loading .dll from vba remember to use PtrSafe in the declare
"Declare PtrSafe Function" Otherwise like Jan said check your configuration variables for folder paths.
Dustin Powell said:remember to use PtrSafe in the declare
It's good to read that you're developing VBA for MicroStation CONNECT.
However, this question is about C# for MicroStation V8i. It's not about VBA or MicroStation CONNECT.
Regards, Jon Summers LA Solutions
true but he didnt say how he was loading the file. that leaves key-ins, automatic config, shortcuts, customized ribbons, 3rd party scripts and vba. also i wasnt sure if ss10 was only 32bit we sorta skipped it. by the way love your site its a great resource.
Dustin Powell said:i wasnt sure if ss10 was only 32bit
MicroStation CONNECT, introduced in 2015, is the first 64-bit MicroStation. All previous versions, including all variants of V8i, are 32-bit.
Dustin Powell said:he didnt say how he was loading the file
MicroStation key-in mdl load AddIn
mdl load AddIn
Dustin Powell said:but he didnt say how he was loading the file. that leaves key-ins, automatic config, shortcuts, customized ribbons, 3rd party scripts and vba.
I have an example (built on year 2014), which was from "Learning Microstation Addins Step by Step". My method to load a DLL files: Utlities->MDL Application->Browse->Select that file (in local drive). Can you guy load this addins nowadays?
7446.csAddins.zip
Jan Šlegr said: caspol.exe (Code Access Security Policy Tool) should be used to check the addin location is still trusted
I am still studying how to use this to check. Likely it passed.
clever_anthony said:Likely it passed.
Yes, nothing clearly bad or weird is displayed.
But: When tested in C:\temp\, is MicroStation configured to load NET addins from this this folder?
clever_anthony said:Can you guy load this addins nowadays?
Yes, no problem with loading in MicroStation V8i SS10, running in Windows 11 ;-)
I placed it to mdlapps folder and I guess it's the place where you should start the testing too. When application cannot be loaded from mdlapps, the problem is likely in the application.
clever_anthony said:I have an example (built on year 2014),
Not very nice dll in my opinion: Targeting NET 2.0 instead of NET 3.5 (even when it is not crucial problem, more cosmetic and systematic issue), referencing native dll, which adds extra complexity when dll is loaded.
Thank you for your help. I wrote addins many years and never noticed that failure would occur if you do not set the configuration variable. In theory, you should be able to load the files which could be in everywhere, the only requirement is: they must be in the local drive.
clever_anthony said:I wrote addins many years and never noticed that failure would occur if you do not set the configuration variable.
That's the standard MicroStation feature from I guess V4, even when how configuration variables work(ed) for old MDL, native code and NET is slightly different.
These variables (like MS_ADDINPATH for NET, MS_MDL for native, for example) are categorized as Primary Search Paths Configuration Variables, so I would assume they are part of both development and administration trainings. And I remember especially configuration for NET was discussed several times in this forum.
clever_anthony said:In theory, you should be able to load the files which could be in everywhere
I what "theory"? They are not executable files, ran by Windows, but MicroStation loads the code to its process and memory space (and application domain in NET). So MicroStation defines what is "loadable", which can be controlled, probably both from historical and technical reasons, by the variables.
clever_anthony said:the only requirement is: they must be in the local drive.
Why? No such requirement exists.
When NET assemblies are discussed, in context of V8i and NET Framework 3.5, network locations are not trusted by default, but it's rights/domains configuration topic, not strict limitation.
Regards,