LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

dlls and manifest files

Solved!
Go to solution

Problem: DLL written in CVI ( for usage with teststand) depends on another DLL, written in MSVC++2008. When trying to use the CVI-DLL in TestStand in fails to find msvcr90.dll. Even after I've ensured that MSVC++2008 redistributables ( 32bit ) are installed.

Problem seems to be that  MSVC++2008 runtime is installed as "Side by Side Assembly" into winsxs directory and therefore some hints in form of a manifest file are needed to find the right runtime.

 

I'am not sure, where i can/have to use the manifest file. Does the MSVC++2008 DLL has to be distributed with the manifest ( either embedded or as seperate file) . Or can I create also a manifest for the CVI-DLL and where I can find documentation for doing so ?

0 Kudos
Message 1 of 3
(3,834 Views)
Solution
Accepted by topic author mkossmann

The manifest file should be in the DLL built in VC. This VC DLL is the one that depends on the 'side-by-side' msvcr90.dll and so must have a manifest declaring this dependency. The CVI DLL has nothing to do with this issue and does not need any manifest - putting a manifest in the CVI DLL would not help. By default, VC automatically embed the manifest when it builds the DLL - so it should already be there in the VC DLL. You can see the manifest by opening the DLL in VC resource editor and looking in the RT_MANIFEST resource section.

 

I think the most likely cause of your problem is that the manifest in your VC DLL points to a different version/build of msvcr90 DLL - this could be because:

1) You are using a debug build. The VC redistributable only installs release build of msvc90.dll and this is different from the debug flavor of msvcr90.dll. Solution: use a release build of your VC DLL.

2) You have a newer msvcr90 DLL on your developement machine (may be because of some patch) but you are installing an older redistributable on the target machine. If so, try patching your target machine. I think 1 is more likely than 2.

0 Kudos
Message 2 of 3
(3,816 Views)

It's probably 2, just because ( if I remember correctly) the debug versions of the VC++ runtime dlls have an additional 'd' in their names.

0 Kudos
Message 3 of 3
(3,799 Views)