WPF Add-in - Not loading an updated dll

Only time I've seen that is when I have the dll located in different folders that are pointed to by the MS_ADDINPATH variable. As a test, I compiled to the Bentley MDLAPPS folder to get something to work, then later change to a folder where our company resources sit. If I don't delete the original, it keeps loading the original dll in the MDLAPPS folder even though later I load from our company folder.

Hi Viktor,

please read and follow this forum best practices and share as much information as possible:

• MicroStation version (build number)
• SDK version
• Where do you place the compiled applications?
• How your workspace (especially MS_ADDINPATH) is configured.

Viktor_Kulik said:

and whenever I load in the dll, it doesn't show any changes, it only shows the original form

What exactly does it mean in terms of used workflow? Do you restart MicroStation to load a new version of your addin?

Viktor_Kulik said:

but for some reason its like Microstation has a cache that it is pulling it from

No, MicroStation has no such cache.

With regards,

  Jan

Hi Jan,

As mentioned, its a Connect SDK, 12.0 if it matters, and obviously I am using Microstation Connect.

I have tried placing the DLL into various places, with same result, in the MDLAPPS folder of SDK, in another folder on C:\ and also in realdwg2018 (although didn't think it would matter). 

My MS_ADDINPATH is currently pointing to realdwg2018 and descartes\assemblies folder. I have also added the sdk\mdlapps folder to it but that didn't make any difference. If I restart microstation, the application is not loaded, and available applications do not show it in MDLAPPS window, then I click browse, pick the dll, and it does get added to Loaded Applications. Then I can use the key-ins such as "wpfsample open" which does open the wpf window, but I have changed parameters, appearance of the form (dragged things around), saved properties, the app still shows as default as it was in the SDK.

If I decompile that dll, my changes are there. I'm going to restart see if anything changes.

Viktor_Kulik said:

If I restart microstation, the application is not loaded, and available applications do not show it in MDLAPPS window

A .NET AddIn is a DLL.  I believe that the MDLAPPS dialog shows only those files having a .ma extension.  Consequently, AddIns are not listed.  I find that confusing too.

Viktor_Kulik said:

I'm going to restart see if anything changes

One of the frustrations of developing a .NET AddIn is that we must exit MicroStation, rebuild the Addin, then restart MicroStation before loading the AddIn.  It's all to do with the AddIn being installed into the host process's address space and the apparent impossibility of the AddIn being completely cleaned out by unloading it. 

I've forgotten the details — it was explained at length many years ago when V8's .NET API was introduced. So how does Microsoft allow .NET apps. with SQL Server?

Viktor_Kulik said:

As mentioned, its a Connect SDK, 12.0 if it matters

It's always required to specify used product version, because it's sometimes hard to guess whether the version information is important or not. In my opinion, because CONNECT Edition now spans 3 years of publicly released 13 versions, the version is always crucial.

Viktor_Kulik said:

I have tried placing the DLL into various places

Why? It does not look like systematic solution. By default, SDK examples are automatically compiled to mdlapps folder and this is default folder that "just works". So to try another location makes no sense and is more like the way to introduce new problems (e.g. left old version(s) in other tested folders not cleaning them) and not solving real problem.

Viktor_Kulik said:

My MS_ADDINPATH is currently pointing to realdwg2018 and descartes\assemblies folder.

It sounds correct. If you use standard SDK example, you do not have to change the variable. When you create managed code project that is built in another folder, you have to modify MS_ADDINPATH.

Viktor_Kulik said:

If I restart microstation, the application is not loaded

Yes, it's expected, no application should be loaded automatically. When properly configured, MicroStation loads application automatically when they are required. But it's a topic for another discussion.

Viktor_Kulik said:

and available applications do not show it in MDLAPPS window

As jon wrote, it's feature of the dialog, it lists native code applications only. Personally I have no problem with this feature (and no my customer), but maybe it's a topic to be formulated as new idea.

Viktor_Kulik said:

then I click browse, pick the dll, and it does get added to Loaded Applications

Why to don't use key-in "mdl load wpfsample"? ... because key-ins are remembered, when application is tested and loaded often, it's quick and simple to select the key-in from history.

Viktor_Kulik said:

but I have changed parameters, appearance of the form (dragged things around), saved properties, the app still shows as default as it was in the SDK.

It seems that old dll is still stored somewhere, but without knowing your environment in detail (MicroStation worksace, configuration of make file / C# project) it's hard to guess where it can be.

Viktor_Kulik said:

I'm going to restart see if anything changes.

As Jon wrote, it's feature, but it's not exactly because of address space (and not only because it's a question what "address space" can be when garbage collector is used). It's defined deep in NET runtime: With some level of simplification, when a code is loaded into application domain, it cannot be unloaded and the whole app domain has to be unloaded from CLR. Because addins are loaded to MicroStation domain, MicroStation has to be restarted.

Jon Summers said:

So how does Microsoft allow .NET apps. with SQL Server?

It's a topic for separate (and lenghty ;-) discussion. I am not sure how exactly CLR procedures are implemented in SQL Server, but a group of limitations and conditions exists also here. But to be able to unload dynamically custom code can be implemented in more ways, but I guess it leads to between domains communication which requires extra coding and there is also some cost to comunicate between domains.

With regards,

  Jan

Thanks for reply Jon,

I am used to restarting the main app for .dll development, autocad has the same requirement. But this current behavior just doesn't make any sense to me. I am just not seeing any change I make to the dll, even after restarting the app or restarting PC completely.

Jan Šlegr said:

It sounds correct. If you use standard SDK example, you do not have to change the variable. When you create managed code project that is built in another folder, you have to modify MS_ADDINPATH.

Well, it sounds correct, but it wasn't... When I mentioned MDLAPPS folder, I was talking about the one in the SDK folder, but you're probably thinking I was talking about the one in Microstation folder. Eh...

My error in this, I understand what it is doing now and was able to get it working.

Still seems weird that although I manually picked a dll from a different location, microstation instead loaded the one in the mdlapps folder.

Now I'm unto doing some more productive code (I'm sure more questions will follow).

Hi Viktor,

Viktor_Kulik said:

and was able to get it working.

It's good to know it works now fine :-)

Viktor_Kulik said:

When I mentioned MDLAPPS folder, I was talking about the one in the SDK folder,

I do not see any mdlapps folder in WPFsample project.

Viktor_Kulik said:

Still seems weird that although I manually picked a dll from a different location, microstation instead loaded the one in the mdlapps folder.

There are no details about how MicroStation NET assembly loader is implemented and my knowledge of CLR internals are quite limited.

But keep in mind you cannot simply select and load managed assembly from any location. It has to be defined in MS_ADDINPATH variable, otherwise it will be not loaded. So maybe when you choose the application, MicroStation prioritized older version probably in MicroStation\mdlapps\ folder instead.

With regards,

  Jan

Hi Viktor,

sometimes it is also good to have a look at "MS_ADDIN_DEPENDENCYPATH". 

Jan Šlegr said:

I do not see any mdlapps folder in WPFsample project.

I think that it is created when you build the sample project, since in the properties, the output folder is set to \MDLAPPS, it's probably meant to be updated, but if you leave it then it creates this folder.