LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VIAssemblyException: Invalid LV Client

I'm working on a proof of concept that involves communicating between a C# application and a LabView-generated .NET interop assembly.  I'm able to build the assembly dll and reference it in Visual Studio.  However, when I attempt to call the external function a run-time exception is thrown (debug output below).

 

The exported function takes an input, doubles it, and sets the result value by reference.  I am using the evaluation version of LabView 2009 however, I don't think that is the issue as I was able to build a shared library dll using the same VI and that worked.  Searches don't yield anything useful about that exception or the message so I'm hoping someone has come across this or knows more about the exception.  TIA.

 

Function prototype:

void Doubler(DBL Input, out DBL Answer)

 

C#:

 

double dblInput = 1.0;

double dblOutput = 0.0;

try

{

    LVClassName.Doubler(dblInput, out dblOutput); // Debug output below when this line is called.

}

...

 

 

Debug:

 

'ClientApp.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\WINDOWS\assembly\GAC_MSIL\NationalInstruments.LabVIEW.Interop\1.0.0.0__daeb5dc76be4e32a\NationalInstruments.LabVIEW.Interop.dll'
A first chance exception of type 'NationalInstruments.LabVIEW.Interop.VIAssemblyException' occurred in SwanTargetFilename.dll
'ClientApp.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Configuration\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Configuration.dll'
.NET assembly call failed: Invalid LV Client.

 

'ClientApp.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\WINDOWS\assembly\GAC_MSIL\NationalInstruments.LabVIEW.Interop\1.0.0.0__daeb5dc76be4e32a\NationalInstruments.LabVIEW.Interop.dll'

A first chance exception of type 'NationalInstruments.LabVIEW.Interop.VIAssemblyException' occurred in myassembly.dll

'ClientApp.vshost.exe' (Managed (v4.0.30319)): Loaded 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Configuration\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Configuration.dll'

Exception message: Invalid LV Client.

Message 1 of 10
(2,574 Views)

Changing the target framework in my C# application from .NET 4 to .NET 2.0 resolved the issue.

Message 2 of 10
(2,558 Views)

That is fine but how do i solve this same issue if i have to use 4.0 in my app because i have other assebmlies that require 4.0 in order to be referenced??

Message 3 of 10
(2,333 Views)

Hello Matma,

 

Unfortunately dlls written in .net 4.0 will not load into LabVIEW, this is a Corrective Action Request (CAR #221992) that R&D is aware of and is looking to fix in newer LabVIEW versions. Any dll written after .net 3.5 will fail to load in LabVIEW; as mentioned above, .net 2.0, is LabVIEW supported. 

 

There was a workaround found that may help some customers: LabVIEW .dll access and callbacks work for .NET Framwork 3.5. Within a C# solution (this customer used Visual Web Developer 2010),  right click on a project and select "Properties".
-Set the Target framework to be .NET Framework 3.5 (do this for any C#  Class Library that LabVIEW will be accessing and any class library that THIS class library will access).

-Class libraries and Windows applications that call the .NET Framework 3.5 .dlls should then be set to .NET Framework 4 Client Profile.
-If you leave it set to .NET Framework 4, all .dlls that this project calls will be compiled to .NET 4.  If set to .NET Framework 4 Client Profile, each individual project within the solution will be compiled to the framework that was specified for that project.
-.NET Framework 4 compiled code can call methods from .NET 2, 3, and 3.5 class libraries. But not vice versa. You can not use a method from a class library compiled in a higher version.
-So, they divided out their class libraries so that anything that LabVIEW needs to access is in a class library in .NET 3.5.

 

Hope this helps,

Deborah Y.

Deborah Burke
Senior LabVIEW Product Manager
Certified LabVIEW Architect
National Instruments
Message 4 of 10
(2,309 Views)

Hello Everyone,

 

In LabVIEW 2011 we document how to use a Microsoft Configuration file to load .NET 4.0 Assemblies into LabVIEW.  The help topic is for LabVIEW 2011; however, this configuration file will work on previous versions of LabVIEW as well.  It is also important to note that without the configuration file (default behavior) you will see the same error as mentioned before.

 

Because of the documentation we have marked CAR 221992 as fixed in the LabVIEW 2011 Bug Fixes.

Regards,

Jon S.
National Instruments
LabVIEW NXG Product Owner
0 Kudos
Message 5 of 10
(2,281 Views)

Having disassembled our labview built assembly, I think im begginning to understand what the issue really is, and why this help doc doesnt work for us.

 

Our Setup:

  • We have both LV2009 and LV2010 installed (LV2010 installed the 2010 runtime engine)
  • Our FPGA and RT Code is built using LV2010
  • Our .Net assembly is built using LV2009
    • Our assembly was built using LV2009 because apparently you cant load LV2010 built assembly in LV2010 due to some known issue.
    • You must therefore build the assembly in LV2009 and then you can load it in LV2010 to test that the assembly code works.

The Problem:

  • However, because we have the 2010 runtime installed we get this error message when trying to load the asembly from visual studio
  • We get this error because the LV2009 built assembly has this hardcoded reference to version 9.0 of the runtime in it
       LvClient.LVRuntimeInst = New LVRuntime(LvClient.EPointNames, Assembly.GetAssembly(GetType(LvClient)).Location, "9.0")
  • Thus we get the wrong client error as the LV2009 assembly is looking for Runtime 9.0 and we have 10 installed.
  • So the issues are the following;
    • That we cant load a LV2010 built assembly in LV2010 thus negate the use of LV2009 and/or
    • That the LV2009 built assembly has a hardcoded version 9.0 check in it.

The Solutions:

  • Now, so that my understanding is correct, since we cant have both runtimes installed on the same machine (i tried and the installer prevents it), for this fix to work we would have to do one of the following;
    • Remove 2010 (and the runtime) and install 2009 and runtime and use the config file fix or,
    • Remove 2009 and build the dotnet assembly in 2010 and then not be able to test it, or;
    • Build the assembly in 2009 for testing and again in 2010 for release and to use this fix.

 

Are these conclusions correct and what are your plans to resolve the identified issues.

 

Thanks

Matt

 

 

0 Kudos
Message 6 of 10
(2,257 Views)

Hello Matma,

 

There's no reason you shouldn't be able to have both run-time engines installed at the same time. Both LabVIEW runtime engines will exist separately, and the target machine will be able to run the executable using the runtime it was built with. You can install as many runtime engines on a machine as you would like, and they will not interfere with one another. At what step does the installer prevent the installation of the 2009 Run-time engine and is there an associated error or dialog box?

 

Thank you,

Deborah Y.

Deborah Burke
Senior LabVIEW Product Manager
Certified LabVIEW Architect
National Instruments
0 Kudos
Message 7 of 10
(2,234 Views)

Hello Matma,

 

Unfortunately that Exception message: Invalid LV Client error is fairly generic and not that helpful, but it usually signals that the application can't find or is missing a dependency. Please double check that you've copied the entire contents of the build directory (from the interop assembly) to where it is being called. If you could post a screenshot or example of what you're doing, that would be helpful.

 

Also, you cannot call a .NET interop assembly in the same version of LabVIEW that it was built in. This was fixed in LabVIEW 2011; however, there are no workarounds for 2009 and 2010. 

 

To clarify on the run-time engine versions, you can have multiple versions of it, say 8.6, 2009, 2010, but you can only have one per year version, meaning that you can't have both 2009 and 2009 SP1. But either one will work to run an application built with either version. Can you elaborate a bit on "we can't have both runtimes installed on the same machine (i tried and the installer prevents it)", because it seems like the quickest thing to get working is having both 2009 and 2010 versions. At what step does the installer prevent the installation of the 2009 Run-time engine and is there an associated error or dialog box?

 

Thank you,

Deborah Y.

 

Deborah Burke
Senior LabVIEW Product Manager
Certified LabVIEW Architect
National Instruments
0 Kudos
Message 8 of 10
(2,200 Views)

Thanks for all the replies but we had deadlines and I couldn't afford to waste more time on this so we abandoned and went with a plain win32 dll.

I don't like, in fact I hate it, but it works and will do for now.

 

[quote]

you've copied the entire contents of the build directory

[/quote]

If the assembly is called from an application "targeting" dotnet 2.0 you only need the assembly itself and it works fine, there is no reason to need other files when targeting other frameworks, not that there are any other files relevant to the assembly in the folder and yes I have tried the .config file fix from the mentioned links/kb

 

 

[quote]

Also, you cannot call a .NET interop assembly in the same version of LabVIEW that it was built in. This was fixed in LabVIEW 2011; however, there are no workarounds for 2009 and 2010.

[/quote]

Yes we know, as above;

  • Our .Net assembly is built using LV2009
    • Our assembly was built using LV2009 because apparently you cant load LV2010 built assembly in LV2010 due to some known issue.
    • You must therefore build the assembly in LV2009 and then you can load it in LV2010 to test that the assembly code works.

 

[quote]

At what step does the installer prevent the installation of the 2009 Run-time engine and is there an associated error or dialog box?

[/quote]

Sorry can't remember exactly now, was a while ago but it was along the lines of "a newer version of the runtime is installed", so I pretty much stopped there as we needed the later version for rt/fpga/dll development..

 

 

Thanks for the help, but i think you can now close this as we wont try using labviews dotnet functionality again.

0 Kudos
Message 9 of 10
(2,193 Views)

Hello Matma,

 

I apologize for the difficulty you experienced implementing this functionality into your program. Please post if there's any content that could be made more clear that you came across during development to help any future similar scenarios.

 

Regards,

Deborah Y.

Deborah Burke
Senior LabVIEW Product Manager
Certified LabVIEW Architect
National Instruments
0 Kudos
Message 10 of 10
(2,165 Views)