.net assembly loads with 7.1. doesn't with 9.0f3

[instrumento]

On the same machine I start LabVIEW 7.1, create a .NET constructor, browse to a given DLL, select a constructor, and I get a .NET object I need.

If I repeat the same steps with LabVIEW 9.0f3 after selecting the proper constructor I get "an error occurred trying to load the assembly.

What gives?

[instrumento]

Doesn't load with 9.01 either (i.e. after applying 2009 SP1).  Same non-descriptive error message.

[smercurio_fc]

Is this a private assembly? Does the assembly depend on other assemblies? Do you have it installed in a specific folder or in the GAC? If it's in a folder is it in a folder that LabVIEW can search? Which .NET framework does it use?

[instrumento]

Don't know what a private assembly is, all I have is a dll.

Yes, it depends on other dlls/assemblies.

No idea what the GAC is. I copied that dll and all other dlls/assemblies to the desktop.

I create a new untitled vi on the desktop and made sure that is the current LV directory.

If I open that vi with 7.1, double click on the .net constructor and point to the assembly, etc,  everything works fine.  If I repeat with 9.0f3 or 9.01, same conditions/sequence, it fails.

I can open/load all other dll/assemblies I have in the desktop, and they were probably generated the same way two or so years ago, and they work with all those versions of labview, but one fails.

I have no idea which framework it uses I have most if not all installed on my machine, up to 3.5.

[smercurio_fc]

While a .NET assembly has a .dll extension, it's not a DLL. I have no idea why Microsoft, in their infinite wisdow, chose to use .dll as the extension for .NET assemblies.

A private assembly is one that you (or someone else) wrote, but did not create a strong name for it. These assemblies are basically "floaters". The GAC is the Global Assembly Cache. Assemblies with strong names can be installed there. The standard .NET assemblies (e.g., System, System.IO, etc.) are in there. It's equivalent to the system32 folder where "system" DLLs can be found.

Dependence on other assemblies is important if those other assemblies are also private. The .NET framework has a specific mechanism for finding dependencies, and LabVIEW is dependent on this. 

As for .NET versions, having .NET 3.5 doesn't mean that the assembly was actually created for that framework as its target. It could have been written for another version. .NET 3.5 includes previous versions of the framework. However, LabVIEW only supports specific framework versions. LabVIEW 7.1 officially supported only .NET 1.1. The patch to 7.1.1f2 included limited support for .NET 2.0. LabVIEW 9 doesn't officially support .NET 3.5 as far as I know. The reason why this might be important is that sometime you have to explicitly configure an application to only use a specific version of a framework. By default, the highest version is used. I had this issue with a .NET assembly I was using. I had to use a .config file to force LabVIEW to stick with .NET framework 1.1 for an assembly I was using until I had upgraded the assembly. Without that the assembly would not load. I'm not saying this is the problem with you, but this can be.

The desktop is a bad place to put private .NET assemblies. Private assemblies should be placed with the code you're writing.

Is it possible for you to upload these private assemblies so others can test this?

[instrumento]

Microsoft chose to use .dll so we could keep referring to .NET linkage problems as DLL HELL instead of NET HELL.

Those assemblies/DLLS/archives/whatever were not in the Desktop.  I just moved them there along with a simple VI to test that this was not a problem of locating the assemblies, along with making the Desktop the current directory.

All these assemblies were created long ago, probably targeting .NET 1.1 or so.  They all worked with Labview 7.1, they still do. I have to double check the dependency tree (I did it using Reflector) but I think more than one depend on one or more in the set but only this one doesn't load.  I'll have to look on how to create the .config file.

Not sure I can upload any of those assemblies, as I didn't create them.  Not sure either if there's any proprietary stuff in them.

[instrumento]

Utterly confused by now.

Control panel/add remove programs shows these versions of .NET:  v1.0.3705/v1.0 Hotfix/v2.0/v2.0 Lang Pack DEU/v2.0 SP2/v2.0 ?? Lang Pack/v3.0 SP 2/v3.5 SP1.

Registry \\HKLM\Software\Microsoft\NET Framework Setup\NDP has entries for v1.1.4322, v2.0.50727, v3.0 and v3.5.

Under %SYSTEMDIR%\Microsoft.NET\Framework I have v1.0.3705, v1.1.4322, v2.0.50727, v3.0, v3.5.

A .NET version check program I downloaded off the web shows 1.0.3705.606, 1.1.4322.2443, 2.0.50727 and 3.0.4506.3613 (no 3.5??)

I have about seven .NET assemblies, red gate reflector shows requirements of 1.0.3705, 1.1.4322 and 2.0.5727.

The assembly I'm having trouble loading targets 1.1.4322 but depends on at least another assembly that targets 2.0.5.727.  However, another with the same type dependency loads normally.

Playing with different LabVIEW.exe.config .NET config files of the form:

 <?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <startup>
    <supportedRuntime version="v2.0.50727" safemode="true"/>
    <requiredRuntime version="v2.0.50727" safemode="true"/>
  </startup>
</configuration>

 using different version numbers and both LV 7.1 and 9.01 I get the results below:

With 7.1:

- no config file:  works

- v1.0.3795:  opens the assembly, shows no objects

- v1.1.4322: opens the assembly, shows no objects

- v2.0.50727: works

- v3.0.4506: labview complains that I need to install a framework

with 9.01

- no config file:  labview generates "an error occorred while loading..."

- v1.0.3795: labview asks for .net 2.0 or later

- v1.1.4322: labview complains that the file is not a .NET assembly

- v2.0.50727: labview generates "an error occorred while loading...

- v3.0.4506: labview complains I need to install version 3.0.4506

- v3.0: labview generates "an error occorred while loading...

- v3.5: labview complains I need to install version 3.5

NET HELL fun, I might say...

[smercurio_fc]

What happens if you open the 7.1 VI with the constructor already in place in LV 2009?

[instrumento]

It's broken, that's how this all thing started, as I try to open all VIs with 2009, migrate them and save them as 2009 versions.

[Manooch_H]

Please see if this KnowledgeBase article addresses the problem you are encountering:

How LabVIEW Locates .NET Assemblies

Hope this helps.