Linking to .Net nodes - "An error occurred trying to load this assembly"

[Daklu]

[Cross posted to LAVA]

Okay, here's an issue that has me completely stumped. I have a third party mixed mode (managed and unmanaged code) assembly that I'm trying to link to from Labview. I've done the usual things, such as creating a unique project file and putting the assembly in the project directory, read through previous forum posts, etc, to no avail.

Using the Select Object from Assembly dialog always returns the generic "An error occurred trying to load this assembly." DebugView returns an equally unhelpful error message: "DNError: (3)." The assembly loads just fine in .Net Reflector and I can link to it and compile from Visual Studio. Fusion Viewer (FV) shows that the assembly *is* being loaded... for some reason Labview doesn't know it.

Any ideas?

*** Assembly Binder Log Entry  (6/8/2010 @ 8:57:02 PM) ***

The operation was successful.
Bind result: hr = 0x0. The operation completed successfully.

Assembly manager loaded from:  C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll
Running under executable  C:\Program Files\National Instruments\LabVIEW 2009\LabVIEW.exe
--- A detailed error log follows. 

=== Pre-bind state information ===
LOG: User = REDMOND\daklu
LOG: Where-ref bind. Location = C:\scc\attg dev\DotNet\Instruments\Flashcut\trunk\bin\remote.dll
LOG: Appbase = file:///C:/Program Files/National Instruments/LabVIEW 2009/
LOG: Initial PrivatePath = NULL
LOG: Dynamic Base = NULL
LOG: Cache Base = NULL
LOG: AppName = LabVIEW Domain for Reflection
Calling assembly : (Unknown).
===
LOG: This bind starts in LoadFrom load context.
WRN: Native image will not be probed in LoadFrom context. Native image will only be probed in default load context, like with Assembly.Load().
LOG: No application configuration file found.
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v2.0.50727\config\machine.config.
LOG: Attempting download of new URL file:///C:/scc/attg dev/DotNet/Instruments/Flashcut/trunk/bin/remote.dll.
LOG: Assembly download was successful. Attempting setup of file: C:\scc\attg dev\DotNet\Instruments\Flashcut\trunk\bin\remote.dll
LOG: Entering run-from-source setup phase.
LOG: Assembly Name is: Remote, Version=4.0.0.15, Culture=neutral, PublicKeyToken=null
LOG: Re-apply policy for where-ref bind.
LOG: Where-ref bind Codebase does not match what is found in default context. Keep the result in LoadFrom context.
LOG: Binding succeeds. Returns assembly from C:\scc\attg dev\DotNet\Instruments\Flashcut\trunk\bin\remote.dll.
LOG: Assembly is loaded in LoadFrom load context.

[jareds]

Hi Daklu,

Where is this Log Entry from?  Have you been able to load .NET assemblies with LabVIEW before?  It sounds like something may be preventing LabVIEW from accessing the assembly properly.  Have you always had a debugger attached to the assembly while trying to use it with LabVIEW?

[Daklu]

"Where is this Log Entry from?"

The log is from the Fusion Log Viewer.  Fusion is .Net component that searches for and loads assemblies when the runtime engine has to resolve an assembly reference.  (Not to be confused with the Fusion Framework, which is some sort of intelligence sharing solution for government.)  It is installed with Visual Studio or as part of the .Net SDK.

"Have you been able to load .NET assemblies with LabVIEW before?"

Yep, and I don't have any trouble creating references to other assemblies from Labview.  However, I've never (knowingly) tried to reference a mixed mode assembly before so I wonder if that has something to do with it?

"It sounds like something may be preventing LabVIEW from accessing the assembly properly."

I agree, hence my question.  🙂  I have tried linking to the assembly using two other computers with the same results. 

"Have you always had a debugger attached to the assembly while trying to use it with LabVIEW?"

Fusion Log Viewer isn't a debugger, but this problem occurs regardless of any other tools I have open at the time.

Message Edited by Daklu on 06-13-2010 07:24 AM

[iZACHdx]

Hello,

Are you running LabVIEW 2009 SP1 or are you using one of the patched versions of 2009? I would agree that mixed mode assemblies do have the ability to make things interesting. Do you have the ability to change that for testing purposes? I believe what jareds was referring to when he asked if you were able to load this before is whether this is the first time you've used this assembly or if you have used it successfully in other LabVIEW versions. Finally, have you tried compiling the assembly in other versions of the .NET framework?

-Zach

[Daklu]

a) Labview SP1.

b) We do not have the source code for this assembly, so I can't change it to a pure .Net assembly or compile it against a different version of the .Net framework.

c) I have not used this assembly from within Labview before.  Either I'm misunderstanding how Labview uses assemblies at edit time or this assembly was written in a way that somehow confuses Labview.

I've always assumed Labview doesn't actually invoke a constructor at edit time and just uses reflection to get the assembly's public members for the Labview invoke and property nodes.  Is that correct?

[christian_w]

Just an idea...

This could be a version conflict. Maybe a dependend GAC registered assembly ?

[jareds]

Hi Daklu,

I am not sure exactly what LabVIEW does with the assembly at edit time.  I would guess that LabVIEW loads the assembly and would probably load any of it's dependencies as well.  Do you know what version of .NET the assembly was created in and do you know what version is on your computer?

[Daklu]

I don't know which version of the framework was used for development, but framework versions 2.0 - 3.5 all compile to the CLR version 2.0.  I have the following versions of the framework installed:

v1.0.3705

v1.1.4322

v2.0.50727

v3.0

v3.5

v4.0.30319

New information...  the assembly I'm having trouble with (remote.dll) links to a native dll (remoteloader.dll) which links to an executable.  I don't know if they use implicit (static) or explicit (dynamic) linking.  At runtime the dlls need to be in the same directory as executable.  In Labview if I attach to remote.dll in the executable's directory it works.  If I attach to a copy of the dlls that aren't in the executable's directory, I get the error.

Here's what I don't understand...

I can add a reference to the dlls from Visual Studio even if they aren't in the executable's directory.  I get all the intellisense and namespace information in the dev environment.  Visual Studio appears to reflect remote.dll for the necessary information and stop there.  Perhaps Labview loads remote.dll AND tries to load all of the dll's dependencies, even though they're not needed until run time?

[Daklu]

---

@Daklu wrote:

I don't know which version of the framework was used for development, but framework versions 2.0 - 3.5 all compile to the CLR version 2.0. 

---

To clarify, this assembly uses CLR version 2.0.

[jareds]

Hi Daklu,

So it works fine if the assembly is in the same directory as the executable?  I wouldn't be too surprised since LabVIEW needs to validate everything at edit-time as well as run-time, since the VI is compiled as you edit it.