New version GAC assembly has new method name，how to make both coexist?

[avater]

My software uses a Net Assembly located in GAC,that is c:\windows\assembly.

Now a new version updated that there're 2 assemblys located in the same GAC.That means,a assembly has 2 versions.

I just want my software yo be compatible with 2 versions.Not just one of them.(I know how to let  Labview load specific assembly)

I can let the deploy PC has only one version of assembly.But my develop PC will have to have both of them.

Here is the problem:

Old version assembly has a method ,and the method's name changed in new version Assembly.

You know when a VI call the method, it can only use the Assembly Labview loaded.That means I cannot has 2 VIs to adapt the method with different names.

Yes,I can build seperately with each Assembly,but I want a single build that can adapt both according to xxx.exe.config.

Thanks for any suggestion!

[GerdW]

Hi avater,

---

@avater wrote:

Here is the problem:

Old version assembly has a method ,and the method's name changed in new version Assembly.

You know when a VI call the method, it can only use the Assembly Labview loaded.That means I cannot has 2 VIs to adapt the method with different names.

Yes,I can build seperately with each Assembly,but I want a single build that can adapt both according to xxx.exe.config.

---

Create a VI for each of those 2 assembly versions.

Then call the VI using VIServer methods depending on which assembly version you want to call…

[avater]

Sorry,I can't  get your idea well.

You mean call VI dynamiclly by VI reference?

Yes I can create 2 VIs for each version,but Labview can only load on version,which means only the according VI is OK,while the other VI is broken.

So if VI is broken,how can I build the whole project?

[GerdW]

Hi avater,

---

@avater wrote:

You mean call VI dynamiclly by VI reference?

Yes I can create 2 VIs for each version,but Labview can only load on version,which means only the according VI is OK,while the other VI is broken. So if VI is broken,how can I build the whole project?

---

Yes, call the VIs dynamically depending of the assembly version you want to use.

The "whole project" will not "brake". (The project file will never give errors, only the VIs when called with the wrong assembly.)

In your first message you wrote:

---

@avater wrote:

(I know how to let Labview load specific assembly)

So it should be possible to call the correct VIs depending on the specific assembly, which you know how to load…

[avater]

Yes,the caller VI is not broken.

But when I try to build the project,it prompts that there is a broken VI.

[GerdW · Accepted solution]

Hi avater,

here is a recent message from RolfK on a very similar problem to yours: how to cope with different Excel versions when the behaviour of ActiveX nodes changes between them…

You need to do the same for your assembly!

[avater]

Thanks for your kind.

It is similar problem as I have ,but still there isn't a good solution.

[GerdW]

Hi avater,

blame the creator of that assembly for changing the method's name for no good reason!

(There could have been a new method with new name and a default error message for the old method in that new version of the assembly instead…)

[avater]

Absolutely agree with u.

[rolfk]

---

@avater wrote:

Thanks for your kind.

It is similar problem as I have ,but still there isn't a good solution.

---

It's the lazy programmer problem. I need to add this new parameter to the function and am to lazy to create a new function with a different name, so I just tag it to the old function. In ActiveX this could work because the ActiveX standard allowed for optional parameters. That however requires the caller to query the ITypeInfo specification of the API, which of course is an optional feature of an IDispatch interface. So even if it works for a specific API, which is not guaranteed since the ITypeInfo is optional, it is a pretty inefficient way of calling an API method. In absence of the ITypeInfo interface you could also go and enumerate all the ActiveX servers in the system and then load their type library and then enumerate all the ITypeInfo objects in there until you hopefully find your API, but that is what LabVIEW for instance does when you open the ActiveX class browser window and I'm sure you agree that that would be terrible to have to do before a first call to a ActiveX method. That and the same two reasons explained below for LabVIEW not to support .Net dynamic parameters at runtime is the reason that LabVIEW won't support that for the ActiveX interface either. 

.Net has also optional parameters but to support that in  non-.Net environments one has to use reflection. LabVIEW does support that internally but does not expose the .Net reflection interface with standard methods, nor does it use it before every call to adapt dynamically to changing APIs. This has basically two reasons:

1) LabVIEW as a strongly typed and fully compiled language can't adapt on the fly to a different API. It requires changes to both the data interface representation on the diagram as well as recompilation of the code.

2) Reflection is highly inefficient. What would otherwise be simply the pushing of some parameters onto the stack and a single call instruction to jump to the target function turns into a whole series of reflection API calls and dynamic manipulation of parameters lists that the reflection interface then has to push on the stack and invoke the target function with. That is not just some percentage of performance loss but in the order of several magnitudes.

However you can call .Net functions to do your own reflection calls. It aint pretty nor easy but it's doable.