LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

.NET8 - An error occurred trying to load the assembly

Hi there,

 

We are trying to call .net8 code from new LabVIEW 2025Q3 and the following error is thrown:

 

Photo.png

 

Exactly the same code works without issues in new TestStand 2025.

Is there a way to get more detailed logs what is happening?

0 Kudos
Message 1 of 5
(150 Views)

I'm not on 2025 yet but on plain .NET on earlier versions there isn't a way to get better logs.

 

The most likely suspect would be that there's a dependency to that DLL that TestStand was able to find but that LabVIEW couldn't.  I am only guessing this because the assembly name literally has "TestStand" in it, so it seems likely it was purpose-built to run there.  I would suggest getting a DLL analyzer program to see what assemblies it references that aren't Windows/System ones.

 

Is this the same PC with the working TestStand implementation of the DLL or is it a different one?

0 Kudos
Message 2 of 5
(112 Views)

Thx for comment.

 

This is our dll, it is compiled as self contained so all dependencies should be in the same directory.

For some reason when compiled for net4.8 we were able to load it in LabVIEW, for net8 this issue happens.

For TestStand it loads and works for net8. Some detailed log that can be enabled would be nice - to see what is missing etc.

0 Kudos
Message 3 of 5
(92 Views)

Is it build as .net8 core ?

As far as I know, LabVIEW only supports .net core. and only partly. 

0 Kudos
Message 4 of 5
(83 Views)

@pawhan11 wrote:

Thx for comment.

 

This is our dll, it is compiled as self contained so all dependencies should be in the same directory.

For some reason when compiled for net4.8 we were able to load it in LabVIEW, for net8 this issue happens.

For TestStand it loads and works for net8. Some detailed log that can be enabled would be nice - to see what is missing etc.


The way LabVIEW deals with .NET DLLs is through a system of calls in a namespace called "Reflection", which funny enough you can also call through LabVIEW.  So, you could try calling Assembly.LoadFrom() on your DLL's file path, and see if that gives you an exception which might provide more information as to why it failed.  If you don't get an exception, then you can continue, such as by running GetTypes to get all the contained types in the assembly and getting all the methods, properties, and constructors in there.  If you're "lucky" maybe you get an exception somewhere in there that points towards a solvable issue.

Message 5 of 5
(51 Views)