force LabVIEW to find a DLL

[DianeS]

Hi all,

I'm working with a custom set of .NET DLLs to communicate with some hardware.  One of the DLLs has constructors and methods which I access in my VIs.  The second DLL is called by the first DLL -- I never directly interact with it in LabVIEW.

I am consistently receiving error 1172 -- LabVIEW is unable to find that second DLL.  Where do I put the wretched thing so that LabVIEW will find it?  Or how do I tell LabVIEW where to look? I have tried putting it in the same directory as the DLL I do interact with.  LabVIEW can't find it.  I have tried putting it in the current directory (I obtained the current directory using the SysExec and the cmd /c chdir command) and LabVIEW can't find it.  I've tried putting it in C:\Windows and that doesn't work.  I've tried putting it in the same directory as LabVIEW 2012.exe and that didn't work.  I have browsed the forum, perhaps searching the wrong keywords.  I have read the LabVIEW help for .NET.

It seems like this should be a simple thing and I'm about ready to scream with frustration.

Help?

Thanks!

d

[DianeS]

I should specify that these are .NET assemblies with a .dll extension.

[DianeS]

Correction.  The first DLL, the one that I'm accessing from LabVIEW, is a .NET assembly.  The second DLL, the one used by the .NET assembly (the one LabVIEW can't find), is not.  Or so the developer of same informs me.

A trip to the MSDN website revealed the following:

The DllNotFoundException is thrown when a dynamic link library defined by the System.Runtime.InteropServices.DllImportAttribute attribute or a comparable language construct, such as the Visual Basic Declare statement, cannot be found. It is not thrown when the common language runtime is unable to load a .NET Framework assembly.

Note that the DllImportAttribute can specify the path to the directory in which the DLL resides. If a path is not specified, Windows uses the search order described in Dynamic-Link Library Search Order.

Hm.

[smercurio_fc]

Do you know if the developer explicitly set the path via the DLLImportAttribute?

Have you tried using this in another environment, like C# or VB.NET?

[DianeS]

Hi Saverio,

The developer tells me he tested this in C# and didn't have a problem.  I'm the first one to try to work with it in LabVIEW.

I don't know if he used DLLImportAttribute to explicitly set the path or not...I'll ask him.  I suspect he didn't, because he's just kept telling me to put the DLL in the search path...which I have.  I looked into where LabVIEW searches for the DLLs, and tried putting the (supposedly) missing DLL in every location in the search path, and LabVIEW keeps throwing this exception.

I'm going to send him my VIs (I create the constructor, register for a callback event, then invoke a method which requires the DLL -- LabVIEW throws the exception at the invoke node) this morning to see if he can reproduce the problem.

I'll post back with an update when I know more...in the meantime, if you have any other ideas, I'd love to hear them!

Thanks,

d

[Matthew_Kelton]

You could try the system32 directory.  He may not have meant the LabVIEW search path but the Windows PATH environmental variable.

[DianeS]

Hi Matthew,

I have, indeed, tried putting it in the system32 directory.  No dice.  But thanks for the suggestion!  To recap, here's where I've tried putting it:

- the same folder where the .NET assembly that calls it resides

- the same folder where the calling VI resides

- the application directory (using Application Directory.vi to obtain the path)

- the current working directory (using the SysExec as described earlier in this thread to obtain the path)

- C:\Program Files\National Instruments\LabVIEW 2012

- C:\Windows

- C:\Windows\System32

He's investigating this morning and should get back with me shortly.

Diane

[DianeS]

Update:  my developer, John, wiggled his fingers and worked his magic and the code no longer throws exception 1172 when I run the invoke node.  He was able to reproduce the problem on his end in LabVIEW, but not in C#.

However...with the new .NET assembly and DLL, LabVIEW crashes as soon as the subVI containing the code has finished executing.  I have stepped through the code and no errors occur -- but then LabVIEW barfs.

It's sort of like fighting the Hydra.  Solve one problem, two more crop up to take its place.

John is able to reproduce this behavior on his end also -- he works from home, I'm onsite in the lab -- so at least everything's consistent.

If it turns out to be a LabVIEW problem, I will update this thread.  If it turns out that the problem is somewhere in the .NET assembly and/or the DLL, I won't.

[DianeS]

Well, it turns out that LabVIEW is getting all up in arms about the fact that the .NET assembly calls the DLL.  John says he knows where it's failing, but doesn't know why or how to fix it.

I've directed him to this forum in hopes that his ability to describe the exact problem will enable some of you to come up with suggestions.  I don't know enough about what he's doing to be able to give the rest of you sufficient information to allow you to help.  I will have him continue in this thread.

[JohnCullison]

Hi, I'm the C++/C# guy.  I have a C# layer DLL which sits atop a Win32 DLL where the actual action occurs.  In order to fix the original problem, I switched from letting .NET access the Win32 DLL (but not finding it under LabVIEW) in the "just works" style to using LoadLibrary/GetProcAddress to explicitly load the Win32 DLL with an explicit, full pathname (which is computed at runtime).  Anyway, the LoadLibrary and GetProcAddress portions are running fine, and I can even invoke the function that the address refers to, which returns a COM Interface.  Doing just this, LabVIEW works fine.

It's using the returned COM interface at this point, from within C# (called from LabVIEW), which ultimately results in the failure.  The failure doesn't occur right away.  It happens when stepping out of my test VI (constructor node, invoke node, close node) -- the final Step Out results in a hard crash (I sent one instance of the bug report up to NI) -- it's a C0000005, which is confusing, since C# isn't catching this access violation.

Naturally, this all works fine from a test C# app which calls the C# DLL which calls the Win32 DLL.

Any ideas?  I am anticipating having to rearchitect this whole thing to make it LabVIEW compatible.