.net assembly promoted to later version

[Cerny]

Hi!

I have a problem!

I am using the .net constructor node with a supported dll.

Now i got a update of the dll, where the assembly version has changed. I copied the new dll over the old one.

Now every time when i press "select Constructor", i get the message -"The version of the assembly you requested was automatically promoted to a later version by the .NET runtime engine." -, but the "select .NET Constructor" dialog box doesn't appear!

OK! So i replaced all existing .Net constructor nodes with empty ones. Then i selected the new dll (the old assembly version was still in the assembly list). When i opened the project again, and tried to view the selected assembly, the same message appeared and i couldn't select the assembly again!

I searched all over my harddrive if any other version somewhere exists. Nothing found so far! And i couldn't find any reference to dll of the old version.

Can anyone give me a hint?

Thx

Markus

[Cerny]

OK! I think i found the problem and a workaround.

As it seems, when i replace the current .net constructor with an empty one, the assembly version will be still saved in the source code of the vi.

The only way to replace it, is to delete the constructor, save the vi, then place a new constructor and select the assembly again.

As i have a lot of constructors in place, it's a lot of work but it seems to work fine then.

Does anyone has a better idea to resolve the problem?

Thx

Markus

[erls]

I'm bumping this thread...

I have the same problem with .NET references and strict type defs.  I'm building an API for a series of 3rd party assemblies and those DLLs get updated on a daily basis.  Once the DLLs have been updated on the compile server, when i open the labview project, all VIs that use strict typedef'd .NET references are broken.  If i open the .ctl and try to manually select the .NET class, i get this message: "The version of the assembly you requested was automatically promoted to a later version by the .NET runtime engine." and LabVIEW fails to load the assembly.  I'm trying to make a build script for automated build/compile of the labVIEW API.

Using LabVIEW 8.5, 8.6 and 2009

Any ideas on what i can do to avoid this?

[Grant_C]

Hi all, i used to use this method of deleting the constructor and closing then re-pasting an empty constructor to point to a particular .dll.

But my problem now is that i have a sunversion tagged .dll called "v246" and a new .dll called "v265" and am unable to use this method to get LabVIEW to point to the latest v265.  Keeps telling me automaticcaly promoted to v246?

I can confirm that i am able to point to v265 using a blank .vi but i want to edit an existing .vi  Apart from the constructor, what else would hold onto the link?

Also if i delete v246 temporarily, i have no problems pointing the constructor to v265 which i would expect.  But i need to keep older version of the .dll so that i know what i used when developing a particular .vi

Any help would be gratefull.

[lv_amateur]

Now I am sitting with this problem. Is NI unable to give an answer to this?

[christian_w]

read this about Redirecting Assembly Versions

hope it helps

Christian

[lv_amateur]

Thanks for the speedy response, but nope, this did not help.

In the list when I choose the .net control, it shows all the versions of the control for every time I recompiled. Maybe it would help to somehow get rid of the previous versions. Where is Labview picking up this list from? I dont see this is the GAC.

[EWiebe]

I have similar problem:

When I update my (self-written) assembly with a newer version and open LabView (2011 SP1 F3) it tells me in a warning that LabView has found a newer version of an assembly.

--> OK, press ignore: I know, there is a new assembly.

The VI is still runnable, but:

THE BEHAVIOUR is different, so it does not execute the right functions and when it executes the function, there appear very strange errors.

So, it is a big problem.

Workaround: when I re-select the constructor (select on ather constructor and select the correct again) and re-select the used methods, it works fine

@NI

Please suggest, what should I do. I do not want to re-select all constructors and all used .NET methods if I have a new version of an assembly.

I think, it is a BUG

[kahlenberg]

Hi,

I also had this problem and found finally a workaround. Bur first I want to say that it is NOT Labview problem rather, it is a .NET Problem. You write a NET assembly and use it in Labview, but if you used automatic versioning of NET assembly it will cause problems and there are some solutions around, I did not try them. What I do is I deactivated auto versioning of NET assembly, and I always use version 1.0.0.0, I know It is not a good solution but it works so far.

[Rob_Calhoun]

I'm exhuming this topic from the deep past, because I've just figured out at least one cause of this problem and the fix.

In my case, I am building a .NET class from source. Changes to the class were not visible in the class, even when navigating directly to the assembling in question using "Browse".

Bumping the assembly revision from e.g. 4.3.0.0 to 4.3.1.0 added a second assembly to the list, but when manually selecting the later code LabView put up the "promoted to a later version" dialog and still went with 4.3.0.0. The root cause of the problem is that LabView was loading the assembly from the "Release" version of assembly rather than the active (and later, according to most people's definition of that word) "Debug" configuration. This happened even when the debug dll was manually selected. The giveaway was that I could recompile the class .NET with with the LabView VI containing the constructor open...a sure sign that from LabView's point of view, these are not the droids you are looking for. Only after cleaning both the Debug and Release configurations did LabView / .NET framework finally give up on the original class. 

The fix is: 

• Make "Release" the active configuration
• Clean solution
• Make "Debug" the active configuration
• Rebuild all

When you do switch to "Release", make sure you similarly clean out the debug configuration.

-Rob