Showing results for 
Search instead for 
Did you mean: 

How LabView searches for .NET assemblies?


I have a problem by usage of LabView VIs using .NET assembly as a step in a TestStand sequence.

The environment is:

- Win7

- LabView 2010

- Teststand 2010

- .NET Framework 4.0 installed on this computer.

The problem: I use methods and properties of a .NET assembly made by another user in LabView VIs. It is not in GAC. Within a Test Stand sequence VIs shall be loaded, get access to .NET assembly and pass references to .NET objects from and  to another VIs. I have already discussed this proplem (Topic "Passing .NET assembly references from Test Stend to LabView...") and got a solution, which worked  under Windows XP:

Suggested and realized solution

- I put .NET assembly in one and the same directory as LabView.exe

- I use TestStand 2010 in the Development Environment of LabView 2010 

The sequence worked well.

Now I have to migrate to another computer with Win7. I'm not an administrator, that's why neither can I put NET assembly  together with LabView.exe nor create LabVIew.exe.config.

I put .NET assembly in one of LabView directories, which are in the search path: c:\programs(x86)\NationalInstruments\LabView\resources. After I did it my VIs using .NET assembly started to work properly . But my TestStand sequence, which worked well before, doesn't work any more (s.attached error message). The LabView aborts, after that aborts also the TestStand. I put this question again into Test Stand forum, but was adviced to ask LabView specialists: obviously the problem has to do with the way how LabView searches NET assembly.


I would like to get answer to following questions:

1) is the only way to force LabView to load a .NEt assembly is to put the assembly together with LabView.exe?

2) would it help to put NET assembly into GAC?

3) maybe it is not a LabView problem, but Win7 (please have a look at the error message)?


With best regards and thanks in advance for some ideas how to deal with .NET, LabView and TestStand together


0 Kudos
Message 1 of 13

Thank you for useful links. I see that the best way is to use GAC.

By the way, I tried already to put the VI using .NET in a LabView project as recommended by NI. But the result was insufficient: LabView couldn*t load assembly  from the project directory (error 7)

Best regards

0 Kudos
Message 3 of 13

The comment in that KB article about putting VIs that use .NET into a project makes no sense to me. That won't change how the .NET runtime works. I think NI meant to say something else, but I don't know what.

Message 4 of 13

I agree. I tried it because I've read about this possibility several times. Authors insist, that in this case the project will be regarded as an application and as the application always do it will search for DLLs in its own directory.

0 Kudos
Message 5 of 13

Hi pericles,


is LabVIEW locating the DLL now, after you put it in the GAC??

Is your problem now solved, or do you have any other questions??



0 Kudos
Message 6 of 13


I haven't put it in the GAC still, because

1) if I do it as a normal user using gacutil.exe, I get an error "access denied"

2) I work just now remote and can't become an administrator of my computer

3) I asked admin to do it for me, but he hadn't done it yet

Finaly I don't know if it was a good way. The goal of my actions is not only to make LaView load it , but to make TestStand load and execute a sequence step, which loads a LabView VI using .NET. It is still a problem. 

0 Kudos
Message 7 of 13



i hope i understand you right:

If you start only the VI (not with teststand) no errors occur.

Only if you run the VI with teststand the error you attached occures.


Do you run the DLL in LabVIEW with the "Call Library Function Node"?

So you could read that knowledgebase-article:


Further more it could be, that the error occures because you have two MSVCR90.dll's. Look at this link:


I hope these links could help you a bit...



0 Kudos
Message 8 of 13

We are talking about .NET assemblies, here, not DLLs. A .NET assembly may have a .dll extension, but it is not a DLL, and you most certainly would not use the Call Library Function Node to call anything from it. Have you read the messages?



Also, please don't post links that point to internal NI web servers ( The rest of the world cannot see these.

Message 9 of 13

Yes, you understood me right about the  behaviour of the VI as LabView VI and being called in a TestStand  sequence.

The correction of smercurio_fc is true: I use constructors , property nodes and methods, not "Call Libraries node", though the assembly has a DLL extension.

Anyway thank you for an attemp to helpSmiley Happy

0 Kudos
Message 10 of 13