[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

Parents
  • 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. 

Reply Children
No Data