[CONNECT C#] Cannot load dll on Windows 10

Hi all,

I have some custom tools that are developed with C#. With appropriate compiler switches and configuartion I made the code running on both: 32bit Microstation v8i SS3 and 64bit Microstation CONNECT / AECOsim.

It works perfectly on my own developer machine and on my coworkers machines (they dont have Visual Studio or stuff installed) all with WIndows 7 and all with both versions of Microstation / AECOsim.

Now we got some new PCs with Windows 10. Somehow it is not possible to load the dlls into Microstation on that Windows 10 PC. I tried both: Keyin "mdl load ..." and browsing for dll via Mdl-Dialog.
As the workspace is the same, the configuartion is the same and, well, everything else is the same except Windows version I really have no idea what kind of error that could be. Microstation is not helping very much: it just gives me the usual "... could not be loaded".

Maybe someone has an idea where to search for errors? Or even HOW to search? I have no idea. I mean as it is running on the other systems it should not be useful to install Visual Studio on that Win10 machine to try to debug with Windows 10. Or maybe that would be useful indeed?

Regards
Stephan

  • Hi Stephan,

    With appropriate compiler switches and configuartion I made the code running on both: 32bit Microstation v8i SS3 and 64bit Microstation CONNECT / AECOsim.

    can you provide more information how your code is structured? V8i and CE use different API and even when Interop assembly is used, e.g. addin loading process and the code itself is different. So I cannot imagine how your code can work.

    With regards,

      Jan

  • Sure. Inside the csproj files of Visual Studio I worked with lines like the following for the references. And when switching platforms from x86 to x64 inside Visual Studio the path to references were changed.

    <Reference Include="Bentley.General.1.0">
    <HintPath>..\Libs_$(Platform)\Bentley.General.1.0.dll</HintPath>
    <Private>False</Private>
    </Reference>



    Inside the code there were some places where I had to use lines like the following to change the platfrom dependend code. For example the usings:

    #if x64
        using Bentley.MstnPlatformNET;
    #else
        using Bentley.MicroStation;
    #endif


    Or another exmaple would be the Addin class:

    #if x64
        [AddIn(MdlTaskID = "Rahma")]
    #else
        [AddIn(KeyinTree = "Deadflower.Rahma.commands.xml", MdlTaskID = "Rahma")]
    #endif
    
        internal sealed class RahmaAddIn : AddIn
        {
            public static RahmaAddIn s_addin = null;
    
            private RahmaAddIn(System.IntPtr mdlDesc) :
                base(mdlDesc)
            {
                s_addin = this;
            }
    
            protected override int Run(string[] commandLine)
            {
                return 0;
            }
        }

    As stated above everything works pretty fine on my Windows 7 machine. Both.

  • Stephan,

    In addition to Jan's questions can you also provide the following?

    1. What is the exact error number and/or message displayed?
    2. Do you experience problems on clients attempting to load a Release build?
    3. What are your current Project values for:
      1. Solution Configuration. e.g. Debug or Release?
      2. Solution Platform. e.g. ANY CPU, x64, x86, other?
      3. Application Target (.NET) Framework. e.g. v8i: v3.5/v4.0, CONNECT: v4.6.1
    4. If possible zip and attach the output from the MicroStation Developer Shell, type: set > c:\temp\%COMPUTERNAME%-SDKCFG.txt

    Thank you,
    Bob



  • There is no error number. It just says "MDL Loader: unable to load application".

    I have no problems on clients running Windows 7. They can run 32bit version with "old" Microstation and 64bit version with CONNECT. On clients running Windows 10 I try to load Release builds.

    I could zip an csproj file so that you could see all the settings I made. Would you like me to do that?

    Ups, I haven't used the Developer shell. I just compile out of my Visual Studio. Maybe this causes problems on Windows 10 clients?

  • Hi Stephan,

    could you please give us the exact version numbers of the MicroStation CONNECT Edition and .NET Framework installed.
    The use of the correct .NET Framework version is critical with building the dll for use as Addin in MicroStation.
    In the Visual Studio project Properties > Application > target Framework, which target version do you have set?

    E.g. with the recent MicroStation CONNECT Edition Update 7 the target Framework version needs to be set to 4.6.1.

    Thanks
    Artur

  • Hi Artur,

    for Addins running with CONNECT Edition I target at .NET Framework 4.6.1

    But we don't use Microstation CONNECT Update 7. We use AECOsim CONNECT Update 1.
    The exact version number is: AECOsim Building Designer CONNECT Edition Update 1 - Version 10.01.00.36

    Regards
    Stephan

  • Hi all,

    thank you for your help. Unfortunatley it was some rather stupid typo. Usually the addin dlls are stored under D:\Users\USERNAME\Addin. On Windows 10 our IT department changed that path to C:\Users\USERNAME\... I've just missed that device change. Thus the needed configuartion variables were set to the wrong path and the well known behaviour of not loading the addins happend.

    I'm sorry for wasting yout time on that one...

    Regards
    Stephan

    Answer Verified By: Stephan L. 

  • Hi Stephan,

    it's good to know you solved the problem and I am sure you don't have to apologize ;-)

    I have two comments to the discussed issue:

    In my opinion, if your environment depends on the drive change, the configuration should be done in a different way. I assume the folder D:\Users\USERNAME\ is equal to standard Windows users' profile location? In such case you should define the path using standard Windows variables that define the environment:

    # DOS style
    path = %homedrive%\%homepath%\Addin\
    
    # bmake / MSBuild style
    path = $(homedrive)\$(homepath)\Addin\

    My second comment is about sharing a code between V8i and CONNECT Edition API. I remember several discussions about this topic including discussions and possible best practices evaluation during migration workshops done several years ago and the conclusion always was: "don't do it". And I agree fully with that recommendation for (at least) these reasons:

    • NET Frameworks and VS projects are not the same. It's not only about targetted version and referenced assemblies, but also more tiny configuration details in the case of Interop assembly (NET 3.5 does not allow to embed types, in NET 4 you have to configure it). It polute the code by conditional configuration.
    • V8i and CONNECT Edition Interop APIs are not equal, so different addin class attributes, methods that should be overloaded etc. require condition compilation including differences in the project itself (command table embedding).
    • It does not allow to use new NET API in CONNECT Edition. It does not allow everything and old Interop is still required, but in my opinion e.g. to use Primitive and Locate commands from VBA / Interop to create code compatible with V8i is bad design decision in CE, because classes derived from DgnTool (e.g.  DgnElementSetTool) offer much better functionality.

    With regards,

      Jan

    Answer Verified By: Stephan L. 

  • Hi Jan,

    thank you very, very much for the hint about correct configuration. Can I use these in Microstation configuration files? Because then I would do that of course. It is much cleaner and would have saved me a lot of time... I didn't know about that possibility.

    About the second comment:

    I didn't have so much problems with individual configuration of the Visual Studio project files, so I think that is okay for me.

    But code polution is a point. You are right. Now there are some places inside my code where I have all that conditional copy&paste code with slight variations. On the other hand if you have two different projects there would be A LOT more duplicated code I think. Slight smile

    I did indeed use some parts of the new NET API because the old interop seemed to have a bug with the textstyle API for CONNECT. But yes, the new DgnTool API I didn't use. Maybe I have missed something there.

    After all I have to say that my tools are pretty small, not commercial ones and I had to do the porting of the code rather quickly, so I guess it is sort of "okay" to mix those for now.

  • Can I use these [Windows environment variables] in MicroStation configuration files?

    Yes.  If your configuration file uses a macro STEPHAN that is not defined as a MicroStation configuration variable, then it searches the operating system environment table for that symbol.

     
    Regards, Jon Summers
    LA Solutions

    Answer Verified By: Stephan L.