07-14-2010 02:24 PM
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 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.
07-15-2010 10:02 AM
Changing the target framework in my C# application from .NET 4 to .NET 2.0 resolved the issue.
07-14-2011 08:23 AM
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??
07-15-2011 09:35 AM
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.
08-05-2011 02:44 PM
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.
08-08-2011 04:36 AM
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:
The Problem:
The Solutions:
Are these conclusions correct and what are your plans to resolve the identified issues.
Thanks
Matt
08-10-2011 08:39 AM
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.
08-15-2011 12:04 PM
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.
08-16-2011 02:50 AM
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;
[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.
08-30-2011 10:47 PM
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.