.NET DLL filename change

[JonDieringer]

I am working with a .NET DLL from an instrument vendor that automates their software application. I created a class library that wraps a lot of functions that the user might want to use; the class private data mainly stores references to the .NET objects created when calling the .DLL.

The vendor perodically updates their API, and when they do so, they release the new version with a concatenated version number to the filename and but does not change the internal version number. They have made small changes to the methods as well, for example they changed a return from void to boolean. I have found that to migrate to the newer .DLLs, I need to update the constructor, then update all the controls in the private data, and finally go through the library and update any controls in subvis that use these .NET objects as inputs or outputs. Sometimes, I need to refresh an invoke node if they change the name of an argument, but not its data type.

I don't seem to have to do this work in other platforms such as MATLAB; there, I just say where the .DLL is (by filename) and it works. Is there a way that I can use more generic interfaces such that I can move between different versions of their .NET library without making a class library for each one specifically?

[tst]

I'm not familiar with the guidelines for versioning .NET assemblies, but that process sounds off to me. I would have expected them at the very least to also update the internal version number of the assembly.

Anyway, your best bet is probably to make typedefs out of the .NET references. That way, you can probably just link the reference in the typedef to the new assembly and all the call sites of the typedef will be updated automatically. I don't remember if I ever did this myself, but it's worth a try.

I expect you will still need to update the VIs calling the modified methods yourself. If LV doesn't change it automatically, one thing you can try is Ctrl+Shift+Run arrow on the top level VI. This force-compiles all the VIs in memory (or the hierarchy. Don't remember which) and is usually a good way to break VIs which don't detect syntax changes on their own. Note that this can take a while and that then all the VIs will want to be saved, because they were recompiled. It's best to save everything you want before you do this and then close everything without saving after you found the offending VI.