Mixed Mode Library and CRT Dependencies - HELP

Question

Alright, after doing a ton of research and trying almost every managed CPP Redist I can find as well as trying to copy my DLLs locally to the executing directory of the app I cannot figure out what dependencies i'm missing for this mixed mode library.

Basically I have a large C# application and I'm trying to use a mixed mode library I made. On the development machine it works perfect (of course) but deployed when the library needs to be loaded for use it exceptions out because of missing CRT dependencies (I assume).

I have used dependency walker to check all the DLLs referenced and ensured they exist on the deployment machine with no luck, I'm wondering if maybe it's some dependencies that need to be registered that I am missing, but i can't figure out what.

I get the following exception when code tries to instantiate a class from the mixed mode library.

Exception Detail: System.IO.FileLoadException: Could not load file or assembly 'USADSI.MAPI, Version=1.0.3174.25238, Culture=neutral, PublicKeyToken=null' or one of its dependencies. This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem. (Exception from HRESULT: 0x800736B1)

I am compiling the library using VS2008 SP1 with /clr:oldSyntax specified.

The intermediate manifest looks like this:

<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.CRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
    </dependentAssembly>
  </dependency>
</assembly>

I can provide any more information as needed, unfortunately i'm not well versed in making mixed mode libraries so this has thrown me off.

If anyone can offer any advice I would greatly appreciate it!

Answer 1

Did you deploy the CRT libraries on the target machine? Long shot: since you have a dependency on 32-bit code, you should set Target Platform in the Build property tab to x86.

EDIT: trouble-shoot side-by-side resolving problems with the Sxstrace.exe utility, available on Vista.

Answer 2

Typically I've found that the pragma comment style manifest decleration's to be much more error free, from a developer maintenence and an over all build action perspective. The XML manifest's are natoriously snafu.

The fimiluarity with how the linker operates and the usual compilation of C code and the fact that you simply tak this in, onto one of your source files, keeps everything a bit feeling more "together";

#pragma comment(linker, \
    "\"/manifestdependency:type='Win32' "\
    "name='Microsoft.Windows.Common-Controls' "\
    "version='6.0.0.0' "\
    "processorArchitecture='*' "\
    "publicKeyToken='6595b64144ccf1df' "\
    "language='*'\"")

Answer 3

I had a similar problem the first time I deployed a VS 2005 app on a target machine -- had to bring over the MSVCRT80 DLL. Are you saying you already have the 2008 VS runtime library there?

ETA: Also, dumb question, but are you sure you have both the CRT Runtime (linked to above) and the .NET Runtime, with the same version you compiled against (probably 3.5)? You probably already know this (especially considering your score) but they're 2 different things.

Answer 4

I found a solution that seems to work although I don't like it very much.

I had to copy the folders:

Microsoft.VC90.CRT & Microsoft.VC90.MFC

From: Program Files\Microsoft Visual Studio 9.0\VC\redist\x86

Into the deployed application directory, I just can't figure out why this seems to work and the redistributables did nothing.

EDIT: Looking at the manifest I probably don't need to copy the MFC directory

Answer 5

Best way to solve this problem is to download process monitor which is free from: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx

Add a filter to watch only your process and it will show you all file access the process tries. This will show you exactly which dll it can't find.

I always use this when faced with the same problem - if only microsoft filled in the filename in the thrown exception it would all be easier.