views:

376

answers:

1

We have a c++ application which I recently ported from Linux/gcc to build on Windows with Visual Studio 2005. The app uses a 3rd party library which only provides DLLs which use the optimised CRT DLL (i.e. they don't provide equivalents which link to the debug CRT DLL). With VS2005 this didn't seem to be a problem = the debug build found the optimised CRT DLL in the System32 dir.

I'm now trying to build and run our app with VS2008 and the debug build fails to run because it can't locate the optimised CRT DLL (msvc690.dll). The VC9 CRT DLLs are squirreled away in directories with a GUID style name - i believe this is an side-by-side assembly and the app is supposed to locate it using the app's manifest. However the manifest that gets built and embedded in the app exe only specifies the debug CRT assembly:

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
  <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
      <requestedPrivileges>
        <requestedExecutionLevel level='asInvoker' uiAccess='false' />
      </requestedPrivileges>
    </security>
  </trustInfo>
  <dependency>
    <dependentAssembly>
      <assemblyIdentity type='win32' name='Microsoft.VC90.DebugCRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
    </dependentAssembly>
  </dependency>
</assembly>

I'm not a Windows expert (not any more at least) so this is all new to me. What is the correct solution here? Do i need to tell the manifest compiler to add the optimised CRT DLL to the assembly? If so how do i do this?

+1  A: 

Ok. If you open the 3rd party library dll in VS 2008 (make sure it chooses OpenWith>Resource Editor) does it contain a manifest of its own?

If it does, or even if it does not, its also useful to get DependencyWalker to see which exact runtime dlls this third party library is attempting to link to.

The fact that it worked with VS2005, and not VS2008, implies the dll wants to use the releasemode versions of the VS2005 runtime: msvcr80.dll

You mention msvc690.dll, which doesn't ring a bell with me: Visual Studio 6 used the simply named msvcrt.dll - the first version of Visual Studio to use a versioned dll runtime was VS 2003 .NET or something: msvcrt7.dll

Anyhow, IF the 3rd party library does not contain its own manifest resource, then the easiest thing to do would be to add the dependent assembly references to your applications manifest.

There are a number of ways of doing this - you can create a manifest fragement as a XML file and add it to your applications "Configuration Properties > Manifest Tool > Input and Output > Additional Manifest Files"

I find the most convenient way of merging additional dependent assembly directives in VS2008 is to use the linkers /manifestdependency command line option.

If you add the following code snippet to a file in your project, it will give the linker the necessary hint:

#define X_CRT_ASSEMBLY_VERSION "9.0.21022.8"
#pragma comment(linker,"/manifestdependency:\"type='win32' "\
    "name='"Microsoft.VC80.CRT' "
    "version='8.0.??.??' "                         \
    "processorArchitecture='x86' "                                 \
    "publicKeyToken='????????'\"")

The ??'s are there because I don't know the version numbers or public key token of the VS2005 libraries off hand. if you can look them up and fill them in, it should go swimmingly.

Chris Becke
Doh, i meant msvcr90.dll. Tha 3rd party DLL does not contain it's own manifest. If i open it in Dep Walker it has a dependency on msvcr80.dll. After some further investigation i think this 3rd party lib is a red herring. It appears one of our libraries is linking to both debug and optimised CRT DLLs. It happens to be the lib that has the dependency on the 3rd party lib so that may still prove to be the cause but i'll have to scrutinise the project settings to be certain. Thanks for the help anyway, i may be back with more questions.
jon hanson
I had to excplicitly exclude the MSVCRT.lib in the project settings for the debug configuration, then it all seemed to work. I'll mark this answer as correct as it does appear to answer my original question correctly.
jon hanson
Unless the 3rd party "dlls" are actually static libs, I must admit the solution doesn't make much sense. If they are dlls they should be rather insistent about which runtime dll they want. Changing your apps linker settings shouldnt change that, as the 3rd party dlls are already linked.
Chris Becke