LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Calling a .NET 3.5 assembly in LabVIEW (how much trouble am I in now?)

Solved!
Go to solution

Running LabVIEW 8.6.1 (For this project)

 

The customer has supplied an ecexutable built in c# running on the .NET3.5 CRL.  

 

Progress so far:

I have succeded in building the constructor to access the method I need. Call it: "DoTest(in_Param, Out_Param, Out_ID, Out_data, Out_Result)

 

The function first checks in_param (and if I give it a bogus value I get the expected error in result) so I know I've got the constructor right.  However, the DoTest never completes successfully from LabVIEW- although it does succeded from the built application containing the function.

 

 

Big Question! If an app uses the .NET 3.5 CRL can some of its functions be unavailable to LabVIEW?


"Should be" isn't "Is" -Jay
0 Kudos
Message 1 of 12
(7,352 Views)

Jeff Bohrer wrote:

 

Big Question! If an app uses the .NET 3.5 CRL can some of its functions be unavailable to LabVIEW?


Yes. However, it doesn't sound as if that's your problem since you can see the constructor. I think the better question is that you're trying to access an executable using the .NET functions. This is not normally done. The .NET functions are really intended for .NET libraries, not executables. True, an executable is a great big class, but it usually expects to be running in a window.

Message 2 of 12
(7,341 Views)

smercurio_fc wrote:

Yes. However, it doesn't sound as if that's your problem since you can see the constructor.

Great news! 
I think the better question is that you're trying to access an executable using the .NET functions.(No, I have the libraries and am calling into those not the .exe)
 

I am assuming there are some pre-conditions that are not configuring correctly in this case.  Back to the drawing board. Thanks-  the LabVIEW help file is sort of vague about the .NET clr version support.

 

Do you have any good referances on the version support or the differances?


"Should be" isn't "Is" -Jay
0 Kudos
Message 3 of 12
(7,332 Views)
The Help File as well as the Upgrade Notes have always been vague. The only claim is that it "automatically loads the latest installed version of the .NET
Common Language Runtime (CLR)". Nice in theory, but in practice not so much. For instance, reasonable support (i.e., not crashing/not working all the time) for .NET 2.0 wasn't provided until 7.1.1f2. I run 8.2 at work, which is supposed to support .NET 2.0. Well, with a private assembly that I have, LabVIEW can't find some of the properties/methods for some of the classes for the most recent version of the assembly. No other app seems to have this problem.
Message 4 of 12
(7,322 Views)
Ahhh... That

smercurio_fc wrote:
t "automatically loads the latest installed version of the .NET
Common Language Runtime (CLR)".

Explains a bit.

 

I know the app does not run with .NET 4.0 (my latest installed version.)   I'll try uninstalling .NET 4.0 and leave 3.5 tomarrow.

 

I post back after giving this a try.  

 

 

THANKS


"Should be" isn't "Is" -Jay
0 Kudos
Message 5 of 12
(7,313 Views)

smercurio_fc wrote:
The Help File as well as the Upgrade Notes have always been vague.

Hmmm.... A  plea for more clarity in the help files,,e.g,,not perfect NI --- but still keep striving please!


"Should be" isn't "Is" -Jay
0 Kudos
Message 6 of 12
(7,312 Views)
Solution
Accepted by topic author JÞB

Jeff Bohrer wrote:
Ahhh... That

smercurio_fc wrote:
it "automatically loads the latest installed version of the .NET
Common Language Runtime (CLR)".

Explains a bit.

 

I know the app does not run with .NET 4.0 (my latest installed version.)   I'll try uninstalling .NET 4.0 and leave 3.5 tomarrow.

 

I post back after giving this a try.  

 

 

THANKS


uninstalling .NET 4.0 was a success!

 

Again thanks for pointing me in the right direction.  I'll take the Solution and give you the BIG assist!


"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 12
(7,267 Views)

There is a little bit more information in this idea exchange post.

 

With .NET 4.0 Microsoft updated mscorlib to version 4.0.  I'm guessing that if you used .NET Reflector on your assembly it would have a dependency of mscorlib 4.0.  You can direct Visual Studio to compile for a previous version of the framework.  I believe that if you select 3.5 or before you will be using mscorlib 2.0 which we do support.


I am currently in the process of making a KB to better describe this issue.

 

As for official support the documentation is pretty vauge.  We support the .NET Framework 2.0.  We do NOT support new features introduced in 3.0, 3.5 or 4.0.  You can use a later version of Visual Studio to create assemblies but they must be compatible with 2.0.  Microsoft updated the mscorlib for .NET 4.0 so you will need to tell Visual Studio to use a different version of the framework.

Regards,

Jon S.
National Instruments
LabVIEW NXG Product Owner
0 Kudos
Message 8 of 12
(7,238 Views)

Thanks Jon.  I'll certainly look forward to seeing the KB. 

 

Unfortunately you seem to imply that I have control of third-party (or customer supplied)  Processes.  Its interesting that I can declare what .NET framework version my built app will use and cannot control the .NET version from the IDE during development and was required to uninstall .NET 4.0 in order to debug my application during development.  Or is there a workaround available to control this by creating a LabVIEW.exe.config file to declare the .NET revision?

Message Edited by Jeff Bohrer on 05-24-2010 10:42 AM

"Should be" isn't "Is" -Jay
0 Kudos
Message 9 of 12
(7,174 Views)

Jeff Bohrer wrote:

Or is there a workaround available to control this by creating a LabVIEW.exe.config file to declare the .NET revision?


Yes, you can create a LabVIEW.exe.config file to specify the required .NET runtime version. This is actually in the LabVIEW Help.

Message 10 of 12
(7,156 Views)