Generating 'Any CPU' C++ DLL


  • I'm trying to reuse some C++ code in a .NET application, so I created a managed C++ DLL project to contain it.  The DLL compiles and I've been able to use it and verify that it works in an ASP.NET application.

    I now need to use it in a WPF/C# application, and I thought it would be a simple matter to add a reference to the DLL and everything would work.  However, I'm getting this error when I build my WPF app:

    C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets(2341,9): error MSB3171: Problem generating manifest. Could not load file or assembly 'c:\dev\internal_tools\Debug\Tools.dll.manifest' or one of its dependencies. An attempt was made to load a program with an incorrect format.

    My C++ DLL is built for the x86 platform, while my WPF app builds for 'Any CPU', which I suspect means that it builds platform-independent MSIL.  Is this error occurring because the two architectures don't match?

    I have tried to make the WPF app build for the x86 platform also, but I get the same error when I build.

    Is there a way to target my C++ DLL for the 'Any CPU' MSIL platform?  I've tried setting the /clr:pure compiler flag, but it doesn't seem to make a difference.  I have also tried to add the 'Any CPU' platform target, but it isn't available.

    Is there another approach that would be easier?  I considered using an EXE COM server instead.


    Wednesday, March 18, 2009 2:19 PM

All replies

  • Odd problem.  I don't think it is an issue with bit-ness, the tool chain is still 32-bits.  It appears to have a problem with retrieving the manifest from your DLL.  The side-by-side manifest, not the assembly manifest.  In Visual Studio, use File + Open and select your DLL.  Open the RT_MANIFEST node and verify that it looks normal.
    Hans Passant.
    Wednesday, March 18, 2009 7:42 PM
  • Thanks for the comment.

    The manifest is present in the resources for the generated DLL.  I see that the VC runtime library is a dependent assembly, and that it's processorArchitecture is x86.  Could this be the problem?

    <?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">
            <requestedExecutionLevel level="asInvoker" uiAccess="false"></requestedExecutionLevel>
          <assemblyIdentity type="win32" name="Microsoft.VC90.DebugCRT" version="9.0.21022.8" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>

    Thursday, March 19, 2009 2:26 PM
  • That looks normal.  Does c:\dev\internal_tools\Debug\Tools.dll.manifest ring any bells?
    Hans Passant.
    Thursday, March 19, 2009 4:44 PM