call library function side by sdie error

[kimw]

I have a DLL written in C++, after using Labview/Tool/Import/Shared Library (dll) wizard, it created a user lib with the .dll in it. After I put any subvi on the block diagram, it popup an error.

Attached is the dll. Could anyone help me figure out what could be wrong?

Thanks,

Kimberly

[rolfk]

Where is the VI library that the import library wizard generated? What error does popup?

Help us help you!

[kimw]

Hi Rolf,

Thank you for helping me out on this. Attached is the screenshot on steps I took to build the dll vi lib and how the errors are:

If you used the attached DLL I sent on the first e-mail and go through the same steps, you could created the dll vi lib to see if you will get the same errors.

Thanks,

Kimberly

[myle00]

The problem I'm pretty sure is not with LabVIEW but with Windows. I.e. you're missing some dlls. Can you describe where the dlls came from? Did you build it yourself, and if so with which version of MSVC++ did you use (it seemes that's what was used)? 

An additional problem I think is that the build used to build the dlls were debug builds and not release builds. Debug builds need some additonal dlls to run. If these are debug dlls this issue cannot be resolved without installing Visual studio 2008. However, if those were release dlls you'd just need to install this http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=29 to fix it. 

M

[rolfk]

The problem with your attached file is that there is no DLL and I have not the right setup currently to create one from your sources. But I agree with the previous poster, this does definitely not look like a LabVIEW problem. Read on MSDN and other sites about side by side DLLs and what they have to say about it. It's usually to do with .Net assemblies and how they are distributed as part of the application or as system libraries in the gAC instead. So it seems your C++ code is somewhere pulling in .Net dependencies.

[rolfk · Accepted solution]

Seems my system blocked the DLL in the archive on the first download. Looking at the DLL it does import MSVCR90D.dll and MSVCP90D.dll. So yes it is a debug build and can only be loaded on systems that have a debug runtime installed of the Visual C 9.0 system, which means in fact that you need a Visual C 2008 development version installed. Change your project build settings to create a release DLL instead and then make sure your target systems have the Visual C 2008 dinstributable C runtime installed.

[kimw]

Hi Rolf,

Thank you so much for the instruction. yes, after I told the DLL developer to give me the Release version, the Labview shared lib was built without errors.

Also, I built an application and rab on our production PC without even installing the CRT on it. I did install VC++ 2010 Express on my development PC and had to go through the registration process.

I did another similar project, which converted Matlab model predictive control m script to a function, and converted the function to matlab DLL using Matlab compiler, and then I had to use Microsoft Visual Studio 2005 to create a wrapper DLL in order for LabView to call, I remembered to build the Release version DLL and installed CRT on the production PCs. This time, it did not even need to install the CRT.

Thanks again.

Kimberly

[rolfk]

If you have to install the CRT or not depends on the actual OS version you install on. Each Windows system comes with the CRT installed that was current at the time this Windows version was released. So when you have CP you clearly don't need to install Visual C 6.0 runtime or even Visual C 2003. For Vista at least Visual C 2005 is already on and maybe even 2008. etc.

In addition you might have installed other software such as a new version of Internet Explorer that comes with its own current runtime too, so that your system has even a newer runtime installed than what the clean OS would come with.

In your case trying out if it works and only install the CRT if it doesn't is a viable solution. But when you distribute the software it is better to include the distributable runtime by default as otherwise you get lots and lots of unneccessary support calls :-).

[kimw]

Hi Rolf,

Thank you for the suggestion. I will follow up with these recommendations.

Have a great day,

Kimberly