sustainable way for Microstation CE add-in/MDL to be deployed to shared network directory?

Hi Everybody,

I am studying in migrating a set of Microstation MDL files working on Microstation V8i SS10. In the current system, the MDL (.MA) files are deployed in a network folder. With the configuration of MDL directories, they can be loaded by key-ins. Deploying the files to network folder makes it easy for me to upgrade them, because I just need to replace the .MA files in network folder without doing work on individual users' computers.

Now we are studying about migrating these files to the newer version of Microstation CE (MS 2023 if possible, but now only SDK for MS CE is available). I want to use C# to develop the new system because C# is relatively more popular than C/C++. However, my understanding now is that, with C# I will need to compile the code to DLL files and deploy them to each individual computer.

Is there a way to develop the system with C#, but still deploy to shared location to avoid touching individual users' computers?

Thank you!

  • Hi Sui,

    MS 2023 if possible, but now only SDK for MS CE is available

    When you want to develop "pure C#" addins, no SDK is necessary (and documentation can be used from CE ;-)

    I want to use C# to develop the new system because C# is relatively more popular than C/C++.

    To choose language / technology based on popularity is quite bad idea in my opinion. In MicroStation, C# API is almost equal to C++ API, but not completely. So depending on implemented functionality, C# can be dead-end, when the code is polluted by hacks and calling native functions (which can be tricky).

    However, my understanding now is that, with C# I will need to compile the code to DLL files and deploy them to each individual computer.

    Based on what information you decide that NET assemblies must be on local computers?

    This question can be transformed to "What you know about network deployment and security mechanisms in NET Framework 4.6? It is where the discussion should start, because MicroStation does not do anything else than loads assemblies into application domain.

    The only requirement on MicroStation side is proper configuration ... and it was discussed, in relation to NET addins, numerous times in this forum (plus variables like MS_ADDINPATH are documented in MicroStation help).

    With regards,

      Jan

  • You can deploy .NET addins (dll files) to network locations as long as your MS_ADDINPATH variable includes the network folder location. Be aware that Windows will require that you network share location will need to be trusted to allow Windows to load your dll (this is a Windows requirement, not Bentley)

  • Hi Jan,

    Thank you for your input. I have some follow up question.

    1. for developing "pure C#" addins without SDK, I tried to find document from Microstation CE, but couldn't find it under the "Programmed Customizations" folder of the help document "as shown in the screenshot below". The search of keyword "C#" doesn't return any item. Where can I find the instruction?

    2. for the method of letting .Net 4.6 in Windows allow loading DLL from network drive, are you referring to this post?

     https://communities.bentley.com/products/programming/microstation_programming/f/microstation-programming---forum/78891/v8i-c-vb-net-how-to-load-dll-from-a-mapped-drive 

    3. Comparing C# and C++ for customizing Microstatin CE, do you mean the C# API for Microstation is actually built based on the C++ API, such that the C# API may miss some functionalities from C++ API, but Bentley is not very motivated to fill this gap, such that C# may be dead end if I encounter situations that need me to heck C# to call C++ API functions?

    Thank you!

    Sui

  • for developing "pure C#" addins without SDK, I tried to find document from Microstation CE, but couldn't find i

    Of course not, because it is user documentation, not SDK documentation.

    To start with SDK documentation is necessary (and you can use CE U17 SDK to understand 2023 dev, where SDK is not released yet and you really do not need it), and of course also to use Programming Wiki with plenty of useful links.

    But in my opinion the crucial is to learn from examples. As I wrote already: NET addin is nothing special, it's standard C# code (with really only a few special features).

    And when they are not enough, apply / order some "MicroStation C# development training".

    2. for the method of letting .Net 4.6 in Windows allow loading DLL from network drive, are you referring to this post?

    Not at all, it is example where not to start. It looks like lack of some knowledge, because what is valid for V8i is not valid for CE, because NET Framework 3.5 used in V8i was more strict and default rules were different than NET Framework 4.6 in CE.

    Follow Mike's advice.

    do you mean the C# API for Microstation is actually built based on the C++ API

    It's not what I mean, it is reality ;-) ... at least for the most of API classes. I See inside assemblies how it is done.

    but Bentley is not very motivated to fill this gap

    I think such discussion is time wasting activity: Some missing functionality (like placing cell from library) is really annoying and I agree Bentley are not motivated (or have no properly skilled resources now) to fix it. Some other are probably standard bugs in API implementation, and others are not implemented "by design" (performance issues, too complex context or whatever else).

    The primary language for MicroStation was always C++.

    if I encounter situations that need me to heck C# to call C++ API functions?

    To call C++ from C# is standard feature (P/Invoke or using C++/CLI to create own wrappers) and is used often. But it's about balance and analysis what can be done in NET and what requires C++ and what is the best approach in terms of complexity and future modifications.

    Some my projects are completely in C#, some were upfront designed to be split into C# and some parts in business logic are implemented in C++/CLI wrapper, called by C# addin, and Ihave also some tool written completely in C++, because there were too many needs to use C++ features, so for better maintainability it was decided to use C++ only.

    Regards,

      Jan