.NET Assembly loaded from NULL in LabVIEW 8.5

[MRedRaider]

THIS IS AN FYI POST, as I just found the solution myself.

I just upgraded from LabVIEW 8.2.1 to LabVIEW 8.5. I am using .NET assemblies for Database communication (ADODB). When opening the .NET based VIs I was getting the following warning:

.NET assembly expected to be at "" was loaded from "NULL"

This was causing the VI to be recompiled. I saved the VIs, closed the project and reopened it with the SAME result. Warning, recompile, save. The solution that worked for me was to Mass Compile the Directory, versus opening and saving the VIs. Something I should have done to begin with.

Just thought it was strange to see the message repeatedly, even after saving the VIs. Anyone else have this problem or a similar issue with .NET in 8.5?

[MRedRaider]

Just verified another required step on similar project.

You MUST close and reopen the Project or you will still get the warning when you open the .NET based VIs, even after a mass compile.

[jlokanis]

This solution does not work on my system.  I am using other .NET assemblys and I cannot make the error go away:

C:\Development\Source\Common\Utilities\Open Event Log.vi
    - The .NET assembly expected to be at "C:\Development\Source\Common\Utilities\Open Event Log.vi\<GAC>\System" was loaded from "<GAC>\System".

[MRedRaider]

Sounds like a different problem, I was getting "Loaded from 'NULL'" after upgraded my projects from 8.2.1 to 8.5.

Surely someone can chime in about why your .NET based vi was looking in the local folder for the Global Assembly cache. Anyone?

You get this every time? Probably relevant is what version of .NET you have installed?

[jlokanis]

I have 1.1, 2.0 and 3.0 installed.

In this case the VI was referencing .NET 2.0 assemblies.

I have tired to build a new VI from scratch to make this work.  That VI will work UNTIL I load any other VI that has this problem.  The act of loading the other VI breaks my new VI. 

I can just ignore the error, then I cannot build an EXE that calls any of these .NET VIs.

[MRedRaider]

Yuck.

Try opening an error generating VI, go to your constructor and reselect your .NET assembly by hand. I think I had to do this once in the past. It make break your VI if it happens to load a different revision of the constructor.... and here I thought .NET was supposed to FIX DLL-Hell.

Anyone got another idea for jlokanis?

[griffindore]

Please see this thread for a continuation of this issue.