Import Shared Library but unable to load library at call library function node

[David Yee]

Hi everyone,

 

I had linked a *.dll using 'Import Shared Library'. However, I encounter this error once it is done:

 

Your generated files are installed in the following folder:
C:Program FilesNational InstrumentsLabVIEW 2013user.libLabVIEW_Emotiv_emostate_EEG

Parsing header file warnings:
No errors/warnings occurred when parsing the header file.

The following errors/warnings occurred when generating the wrapper VIs for this shared library. 

VI Not Executable
The VI is not executable because of one of the following reasons:
1. The shared library or a dependent file is not installed. To make the VI executable, you must install the shared library and all support files on the computer on which you run the VI.
2. A required custom control might be empty or cannot be found. To make the VI executable, update the custom control manually.
3. The VI contains a parameter with an unsupported data type. To make the VI executable, you must replace the empty cluster that the wizard generates with a control or indicator that uses supported data types.
ARRAY2D.vi
ARRAY2D Handle.vi
Dll Main.vi
LVEE Data Collectfor EEG.vi
LVEE Engine Connect.vi
LVEE Engine Get Next Event.vi
LVEE Engine Get Next Eventfor EEG.vi
LVEE Engine Get Next Eventfor Emostateand EEG.vi
LVEE Engine Remote Connect.vi
LVEE Number Of Data Samplefor EEG.vi
array2ddataoutfor EEG.vi
arraydataout.vi
arraydataouthandle.vi
eegcontrolinitf.vi
eegcontrolstopf.vi
emocontrolinitf.vi
emocontrolstopf.vi

 

And then, when I was trying to create a 'call library function node' , the library failed to load. It comes with this error :

 

'This application failed to start because of its side-by-side configuration is incorrect'

 

Any help is appreciated ^^ Thanks.

[Rolf Kalbermatter]

Hi everyone,

 

I had linked a *.dll using 'Import Shared Library'. However, I encounter this error once it is done:

 

Your generated files are installed in the following folder:

C:Program FilesNational InstrumentsLabVIEW 2013user.libLabVIEW_Emotiv_emostate_EEG

Parsing header file warnings:

No errors/warnings occurred when parsing the header file.

The following errors/warnings occurred when generating the wrapper VIs for this shared library. 

VI Not Executable

The VI is not executable because of one of the following reasons:

1. The shared library or a dependent file is not installed. To make the VI executable, you must install the shared library and all support files on the computer on which you run the VI.

2. A required custom control might be empty or cannot be found. To make the VI executable, update the custom control manually.

3. The VI contains a parameter with an unsupported data type. To make the VI executable, you must replace the empty cluster that the wizard generates with a control or indicator that uses supported data types.

ARRAY2D.vi

ARRAY2D Handle.vi

Dll Main.vi

LVEE Data Collectfor EEG.vi

LVEE Engine Connect.vi

LVEE Engine Get Next Event.vi

LVEE Engine Get Next Eventfor EEG.vi

LVEE Engine Get Next Eventfor Emostateand EEG.vi

LVEE Engine Remote Connect.vi

LVEE Number Of Data Samplefor EEG.vi

array2ddataoutfor EEG.vi

arraydataout.vi

arraydataouthandle.vi

eegcontrolinitf.vi

eegcontrolstopf.vi

emocontrolinitf.vi

emocontrolstopf.vi

 

And then, when I was trying to create a 'call library function node' , the library failed to load. It comes with this error :

 

'This application failed to start because of its side-by-side configuration is incorrect'

 

Any help is appreciated ^^ Thanks.

 

Your DLL depends on an SxS assemby that is not installed on your machine. Most likely it was compiled with Visual C++. You need to find out what version of Vsual C++ was used to compile your DLL and then download the Redistributable C Runtime Library for that version from Microsoft.

 

More generally the manufacturer of your DLL should have provided you with an Installer for the DLL that takes care about installing the DLL on your computer and also install all the necessary dependencies it has.

[David Yee]

Thanks, Aficionado for the advice, really appreciate that.

 

I tried to recompile the dll in VS 2010. Orignally, it was compiled in VS 2008. After recompiling the dll, the is no longer side-by-side configuration error. However, a new error comes up where labview cannot locate "edk.dll" and declared it as missing or yet to be installed eventhough I placed it at the same folder with the dll. Is there any way to enable Labview to  find edk.dll?

 

 

[LogMAN]

Here is the topic to the last question: http://lavag.org/topic/18282-edkdll-missing-eventhough-in-the-same-directory/

[Rolf Kalbermatter]

Thanks, Aficionado for the advice, really appreciate that.

 

I tried to recompile the dll in VS 2010. Orignally, it was compiled in VS 2008. After recompiling the dll, the is no longer side-by-side configuration error. However, a new error comes up where labview cannot locate "edk.dll" and declared it as missing or yet to be installed eventhough I placed it at the same folder with the dll. Is there any way to enable Labview to  find edk.dll?

 

It's not LabVIEW which is searching the dependent DLL but Windows. LabVIEW only knows about the DLL that you reference in the Call Library Node and nothing else. It asks Windows to load the DLL and the Windows loader then finds in the DLL references to other DLLs and tries to load them. For that Windows uses a predefined search strategy and looks in following locations:

 

1) if the same DLL is already loaded in memory it uses that

2) in the application directory (that is the directory where LabVIEW exe resides for the development system and yourApp.exe for a compiled application)

3) in the Windows directory

4) in the system directory

5) in the current directory (typically the directory where your application was started from but also the last directory in which the File Dialog box was positively dismissed inside your application)

6) in any directory that is named in the PATH environment variable

 

Put that DLL in one of these directories (and make sure to include it in any build of your application too) and things will work.

[Neil Pate]

To follow on from what Rolf said, you can programatically set the current directory using the Win32 API. This is often convenient if you know your DLL is in a certain place. I did use this technique many years ago, but have not needed it since.

 

To get an idea on how to do this look at the attached VI (obtained here). 

 

Set Current Directory.vi

[Rolf Kalbermatter]

To follow on from what Rolf said, you can programatically set the current directory using the Win32 API. This is often convenient if you know your DLL is in a certain place. I did use this technique many years ago, but have not needed it since.

 

To get an idea on how to do this look at the attached VI (obtained here). 

 

I would consider modifying the current path (CWD) to achieve this not only hacky but really a potential race condition in a multi-threading system like LabVIEW. There are various Windows APIs which will themselves modify the CWD internally with the File Dialog API being one of the more prominent ones and there is definitely a chance that something else in the application might call some functionality that changes that path between the time you call SetCurrentDirectory() and LabVIEW gets around to load the library. That's admittingly a small time window, if you program your VI right, but the sheer possibility of this makes me run away from this solution. 

[Neil Pate]

I would consider modifying the current path (CWD) to achieve this not only hacky

 

Totally agree with you, but...

 

 

That's admittingly a small time window,

 

Very very small probably if you set the CWD immediately before calling the DLL function.

 

I suppose deciding whether to use this function or not depends an awful lot on the risk of something going wrong combined with the likelihood of it happening. 

[Rolf Kalbermatter]

Very very small probably if you set the CWD immediately before calling the DLL function.

 

I suppose deciding whether to use this function or not depends an awful lot on the risk of something going wrong combined with the likelihood of it happening. 

 

Well yes but the CWD is a broken concept for multithreaded applications anhow. So why trying to risk anything aside from that changing this path might break some other broken implementation elsewhere in your application, like in a third party DLL. 

 

The best solution is to make sure that the DLLs are put in a place where Windows will find them, that would be most likely a directory in the PATH environment variable in the development system and the application directory in a built application.

 

If you absolutely need to trick Windows, I would do it a bit different. Just call LoadLibraryA() with the library path where you now call SetCurrentDirectory(), That loads the library into the process and then Windows will hit that library name in my earlier list in step 1) already. Achieves the same, requires also just one Call Library Node but avoids potential race conditions and breaking other compoments that might rely somehow on CWD being set in a certain way. Just make sure to not call LoadLibrary() many times, and strictly speaking you should also FreeLibrary() but unless you work in a plugin situation where you might unload the plugin sooner than later, it really doesn't make a big difference if the DLL remains loaded in the process until the application is quit.