Unwanted automatic promotion of .NET assemblies

[m3rl3n]

Hi All,

I'm developing on a Windows 10 PC with LabVIEW 2016. The development PC has .NET framework 4.0 installed on it.  The target machine is a PCI chassis with a Widows 7 compatible controller ( running Windows 7) with the .NET 3.5 framework on it.

For configuration reasons, I cannot change the target machine, nor can I install the LabVIEW development environment on it in order to force LabVIEW to constrain to using .NET 4.0.

The problem is that when I try to select the System(2.0.0.0) to get the constructor that I want (System.Timers.Timer), I get a LabVIEW popup that states "The version of the assembly you requested was automatically promoted to a later version by the .NET runtime engine."  (NO. I WANT THE ONE I SELECTED!! STOP TRYING TO HELP ME MICROSOFT!!! - sorry)

Anyway, in doing research I have found within MSDN to turn off the auto promotion by adding the line "<AutoGenerateBindingRedirects>false</AutoGenerateBindingRedirects>" to the Visual Studio config file....  and all manner of "fixing" issue within MS products.

So I tried the following:

I have set the following on my development PC in a LabVIEW.exe.config file:

<?xml version ="1.0" encoding="utf-8" ?>
<configuration>
   <startup useLegacyV2RuntimeActivationPolicy="true">
        <supportedRuntime version="v3.5"/>
   </startup>
   <PropertyGroup>
        <AutoGenerateBindingRedirects>false</AutoGenerateBindingRedirects>
   </PropertyGroup>
</configuration>

It does not help. I still get the same popup and when I build the executable and try to run on the target machine, it does not run, giving me the error that I need .NET 4.0 on the machine.

Any help on what I'm doing or not doing, wrong or right?

[Atizss]

Look at this NI article regarding your issue, perhaps it helps: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P8XnSAK&l=nl-NL

Seems like it is a security issue. It goes further to explain how to load older assemblies: http://zone.ni.com/reference/en-XX/help/371361P-01/lvhowto/configuring_clr_version/

[m3rl3n]

With regards to the second link - I've used that solution for years and it is part of the config file that I posted in the original question.

I tried the actions of the first link and I still have the same pop-up stating that the dll has been promoted to the latest. I stopped LabVIEW and re-started it, but to no affect. Unless for some reason I would have to reboot the PC.

[Atizss]

You are right. I tried it myself, and I could not get it to work. However, I wanted to ask - Is your LabView version 32 bit? It does mention that the error can also occur if you attempt to load 64bit .dll into 32bit LabView. 

[m3rl3n]

Hmmm - I missed that part.

My LV install is a 32-bit.

I would think for backwards compatibility, especially at the system level, MS wouldn't be developing dlls in 64 bit only, but...

But that also doesn't make much sense.  I want to use a system timer available in System.Timer. I'm trying to load / use the 2.0 version of the dll, but either Windows or LabVIEW is automatically promoting to 4.0.  I would imagine if anything, that the 2.0 version may still be in 32 bit and work properly.

At this point my team has a workaround in place, but I don't feel it's proper to be forced into using a dll that I may or may not want to.  If I'm forced to 4.0 this time, what happens in 2 - 3 years when I have to make a change to the code and I get forced to use System(6.0)? What ends up breaking in other parts of the code? 

[Siriusly]

Have you tried placing the "YOURAPP.exe.config" in your application directory with the appropiate name.  I have done this in the past to get my custom application to work with a certain version of .NET.

I had to have one in the LabVIEW directory and the custom application directory

C:\Program Files (x86)\National Instruments\LabVIEW 2019\LabVIEW.exe.config

YourAppPath\\YOURAPP.exe.config