none
Unable to load class library RRS feed

  • Question

  • I wrote a managed wrapper in C++/CLI and compiled it under AMD64.

    Now I wrote a client in C++/CLI too and this works well.
    Trying to do the same in C# I got everything to compile but when I run it it says:

    Unhandled Exception: System.IO.FileNotFoundException: The specified module could not be found. (Exception from HRESULT: 0x8007007E) at MyClass.Main()

    This is weird though. I compiled the C# file for 'anycpu' but trying to set the platform to x64 did not do any difference.

    The class library is even located in the same directory. 

    It was compiled using the RC:
            csc /out:test_cs.exe test.cs /reference:net64.dll
    Microsoft (R) Visual C# 2005 Compiler version 8.00.50727.26
    for Microsoft (R) Windows (R) 2005 Framework version 2.0.50727
    Copyright (C) Microsoft Corporation 2001-2005. All rights reserved.

    The same thing happens in both C# and VB whereas the C++/CLI client works just fine.
    What am I missing here? Actually I am not even sure what file is missing since it does not say in the error message. I just assumed it's my class library.

    Thanks in advance.

    -- Henrik
    Thursday, November 10, 2005 9:37 AM

Answers

  • There are a few things I can think of:

    1. The C# compiler is different than the C++ compiler in the sense that the output files are created directly and do not not require a linker, therefore there is no object output (.obj).
    2. I would not think that the plateform would make a difference. If it does, it would be for the following reasons:
      • You cannot load a 64-bit Library from a 32-bit process. (Except with P/Invoke)
      • You cannot load a 32-bit Library from a 64-bit process. (Except with P/Invoke)
      • Pointer arithmetic is offset. Use the StructLayoutAttribute to align a structure.
        Note: RPC calls are allowed between a 64-bit and 32-bit process.
      • Try compiling the managed wrapper as anycpu. This is determine if the problem is because of the process architecture.
    3. If possible, debug the process and generate debug information by using the /debug switch on the compiler. Run the process using a CLR debugger (Free with the 2.0 SDK) and use the Modules window to view what modules are being loaded, and attempted to be loaded.

     

    Thursday, November 10, 2005 7:13 PM
  • Ok, I do the test and fail, but I changed the way the cl compiler does the dll to this and worked fine:
    cl /clr:pure /O2 /MD /c a.cpp
    Friday, November 11, 2005 3:59 PM
  • I Can see that is a problem of the 64 bit compiler, see this post for more help:
    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=94312&SiteID=1

    I was runing my code in a 32 bit OS.

    Friday, November 11, 2005 6:17 PM
  • It seems I am not the only one facing this issue. Someone already opened a bugreport for it:

    http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=06e0a0c8-30a4-498f-999e-ce06daa355ed

    -- Henrik
    Friday, November 11, 2005 9:05 PM
  • FileNotFoundException is for msvcr80.dll.  The reason why is the C++/CLI client already has a CRT manifest file to begin with so when loading the C++/CLI server without CRT manifest is no problem.  But from C# or VB clients the runtime cannot find the CRT on demand hence given that exception.  Here are some options you can consider:

    1. Make your C++/CLI /clr:safe assembly if possible, that way the dependency on CRT is removed and no manifest file is required.
    2. If your assembly cannot be compiled /clr:safe then you can internalize the CRT manifest file into the assembly.  Here's how you do that:

    For a DLL:
    mt –outputresource:application.dll;2 –manifest application.dll.manifes
    For an EXE:
    mt –outputresource:application.exe;1 –manifest application.exe.manifest

    To fully understand this problem, they should read this topic and the topics it links to:http://msdn2.microsoft.com/en-us/library/ms235560(en-US,VS.80).aspx
    http://msdn2.microsoft.com/en-us/library/zebw5zk9

    Thanks,
    Ulzii-

    Wednesday, November 16, 2005 1:10 AM

All replies

  • There are a few things I can think of:

    1. The C# compiler is different than the C++ compiler in the sense that the output files are created directly and do not not require a linker, therefore there is no object output (.obj).
    2. I would not think that the plateform would make a difference. If it does, it would be for the following reasons:
      • You cannot load a 64-bit Library from a 32-bit process. (Except with P/Invoke)
      • You cannot load a 32-bit Library from a 64-bit process. (Except with P/Invoke)
      • Pointer arithmetic is offset. Use the StructLayoutAttribute to align a structure.
        Note: RPC calls are allowed between a 64-bit and 32-bit process.
      • Try compiling the managed wrapper as anycpu. This is determine if the problem is because of the process architecture.
    3. If possible, debug the process and generate debug information by using the /debug switch on the compiler. Run the process using a CLR debugger (Free with the 2.0 SDK) and use the Modules window to view what modules are being loaded, and attempted to be loaded.

     

    Thursday, November 10, 2005 7:13 PM
  • >The C# compiler is different than the C++ compiler in the sense that the output >files are created directly and do not not require a linker, therefore there is no >object output (.obj).

    No this is not the case. Why do you mention obj files? This should be unnessecary. Only the resulting class library matters which is a dll.

    Your other points are not valid for my case either. All is compiled and run on AMD64 so no Cross-OS stuff is going on.

    >If possible, debug the process and generate debug information by using >the /debug switch on the compiler. Run the process using a CLR debugger (Free >with the 2.0 SDK) and use the Modules window to view what modules are being >loaded, and attempted to be loaded.

    I tried doing that but without luck. No matter what it shows this error and the CLR debugger does not post any information at all.

    Since I still cannot get it working I did a small repro. Could someone be kind to compile this code and tell me if it works on your platform or not. I am interested to see if it works on Win32.

    File a.cpp:

    #using <mscorlib.dll>
    using namespace System;

    public ref class A
    {
    public:
    void CallMe()
    {
    Console::WriteLine(
    "Yeay --- I was called");
    }
    };

    File b.cs:

    using System;

    public class B
    {
    static void Main()
    {
    A a =
    new A();
    a.CallMe();
    }
    }

    Then compile them as:

    cl /clr /O2 /MD /c a.cpp
    link /dll /out:a.dll a.obj
    csc /out:b.exe b.cs /reference:a.dll

    Now run b.exe

    All I get is a file not found by the VM loader.

    Thanks in advance.

    -- Henrik

    Thursday, November 10, 2005 8:55 PM
  • Ok, I do the test and fail, but I changed the way the cl compiler does the dll to this and worked fine:
    cl /clr:pure /O2 /MD /c a.cpp
    Friday, November 11, 2005 3:59 PM
  • Very very bad!

    I tried what you said with the example above but once I got it to compile it runs but at the same time gives a runtime error.

    I get a messagebox saying theres a runtime error R6034.

    Did you also get that?

    /clr:pure is not an option for me though. I am creating a mixed mode library which contains unmanaged code also.

    Should I assume that this is a really critical bug?

    -- Henrik
    Friday, November 11, 2005 4:58 PM
  • I don't get a error message, the program runs fine.
    Friday, November 11, 2005 5:00 PM
  • I Can see that is a problem of the 64 bit compiler, see this post for more help:
    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=94312&SiteID=1

    I was runing my code in a 32 bit OS.

    Friday, November 11, 2005 6:17 PM
  • This is odd though. I don't have any manifest files (only the autogenerated ones). It's really a weird issue though.

    As for the runtime error I guess it's something that is fixed in the final compiler?
    Friday, November 11, 2005 6:39 PM
  • Maybe, I'm using the Final Version of VS2005.

    Friday, November 11, 2005 6:41 PM
  • It seems I am not the only one facing this issue. Someone already opened a bugreport for it:

    http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=06e0a0c8-30a4-498f-999e-ce06daa355ed

    -- Henrik
    Friday, November 11, 2005 9:05 PM
  •  Henrik Goldman wrote:
    It seems I am not the only one facing this issue. Someone already opened a bugreport for it:

    http://lab.msdn.microsoft.com/productfeedback/viewfeedback.aspx?feedbackid=06e0a0c8-30a4-498f-999e-ce06daa355ed

    -- Henrik


    It's good to see this Smile
    Friday, November 11, 2005 9:07 PM
  • Personally I think this bug is beyond critical. Isn't this one of the reasons why .NET framework was invented? To be able to mix languages into the same common language MSIL?
    Lots of good reasons for using C++/CLI goes away if you cannot assume working code.
    So the next obvious quesion should be if C# and C++/CLI does not work together, will VB and C#? I already tested that VB and C++/CLI does not work either. So how about J# and the other languages?

    I surely hope for a resolusion fast.

    -- Henrik
    Saturday, November 12, 2005 8:59 AM
  • I don't understand why but if I build using

    cl /clr /O2 /MD /c a.cpp
    link /dll /out:a.dll a.obj
    csc /out:test.exe b.cs /reference:a.dll

    test.exe runs without any problem. It just won't run for any other name

    Saturday, November 12, 2005 4:51 PM
  • Very weird I did not have the same success. Was this under Win32 and which build?

    I found out the R6034 runtime error problem is related to the redist files. The seem to cause _LOTS_ of problems on my x64 machine when I put them into \windows\system32. I'm running Windows XP pro x64 on that machine.

    I got them from \c\Program Files (x86)\Microsoft Visual Studio 8\VC\redist\amd64\Microsoft.VC80.CRT
    but it seems it was a big mistake since it got my machine to act very weird and I got lots of R6034's in other programs too e.g. when deleting a file in explorer.
    Saturday, November 12, 2005 5:32 PM
  • Yes it's on Win32 (XP SP2)
    Saturday, November 12, 2005 5:48 PM
  • I tried it on Win 2000 and everything works fine. I think the problem is with loading of CRT on XP. The entry for CRT in assembly's manifest is

    <dependentAssembly>
          <assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />
     </dependentAssembly>

    It appears that the CRT version is for older compiler(14.00.50608.0). The compiler available with SDK is of version 14.00.50727.42 and my %windir%\WinSxS
    contains x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd which is CRT corresponding to this version.
    Sunday, November 13, 2005 11:44 AM
  • Very good finding!

    I just checked my manifest file from the RC and it's the same (wrong) version as yours for amd64.

    Now I understand that the missing file error is not our class library but the crt code that it is missing.

    So what did you do under Windows 2000? Did you use the 3 redist files msvcm80.dll, msvcp80.dll and msvcr80.dll without the manifest?

    Still when I try to use the redist files (just by copying them to system32) without the manifest I get R6034's even though they are the correct build for the RC (8.0.50727.26).

    I wonder if there is an updated CRT redist available?

    Very good work so far!

    -- Henrik
    Sunday, November 13, 2005 12:02 PM
  • Actually I tried it under a Win2k machine too:

    I did the following:
    1. Recompiled the library a.cpp into x86
    2. Install .NET 2.0 redist on win2k (latest version from msdn.microsoft.com)
    3. Run it from local machine

    This seems to work.

    -- Henrik
    Sunday, November 13, 2005 2:34 PM
  • Found the solution.

    copy a.dll.manifest b.exe.manifest

    Unlike C++ linker, C# compiler does not create the manifest file required to locate CRT on XP.
    Sunday, November 13, 2005 4:26 PM
  • Thats really great! Thank you for finding a workaround so we can continue our work. :)

    Now we just wait patiently until Microsoft fixes it.

    -- Henrik

    Sunday, November 13, 2005 6:09 PM
  • FileNotFoundException is for msvcr80.dll.  The reason why is the C++/CLI client already has a CRT manifest file to begin with so when loading the C++/CLI server without CRT manifest is no problem.  But from C# or VB clients the runtime cannot find the CRT on demand hence given that exception.  Here are some options you can consider:

    1. Make your C++/CLI /clr:safe assembly if possible, that way the dependency on CRT is removed and no manifest file is required.
    2. If your assembly cannot be compiled /clr:safe then you can internalize the CRT manifest file into the assembly.  Here's how you do that:

    For a DLL:
    mt –outputresource:application.dll;2 –manifest application.dll.manifes
    For an EXE:
    mt –outputresource:application.exe;1 –manifest application.exe.manifest

    To fully understand this problem, they should read this topic and the topics it links to:http://msdn2.microsoft.com/en-us/library/ms235560(en-US,VS.80).aspx
    http://msdn2.microsoft.com/en-us/library/zebw5zk9

    Thanks,
    Ulzii-

    Wednesday, November 16, 2005 1:10 AM
  • Thanks so far.

    I used the trick you gave with using mt for dll's and it seems to work fine. I assume that it imports the manifest into the binary file, right?

    I fail to understand why one must use the resource id ";#2" though? If I use 1 or 3 it does not work.
    From winuser.h it means ISOLATIONAWARE_MANIFEST_RESOURCE_ID but that does not make me much smarter.

    Is this something that will be fixed? I mean this is some kind of bug... right? Not a "feature".

    -- Henrik
    Wednesday, November 16, 2005 8:56 AM
  • Hi,

    I am experiencing this problem as well. I am making a C++ class library, and add a reference (and use) this in a C# class library. The C# library is then again added as an instance to a C# Windows application.

    When I reach the code in the C# class library that tries to instantiate the ref-class of the C++ class library, I get  "FileNotFoundException was unhandled". It does not say anything about what file is missing, and I know that all my own dll-files are within the same folder.

    But my question now is, which manifest file do I need to fix? The one of the C++ class library? On which property page do I do this? And do I need to manually copy this manifest file to the bin-folder of the executing application?

    Thanks !

     

    (I am using WinXP 32-bit all the way)

    Tuesday, February 14, 2006 4:30 PM
  • (This is an old thread, so I hope someone's still looking as I'm still stuck )

    I have the exact same versioning problem you described, but I can't see how your suggested fix works.  Whether I copy the manifest or embed it in the dll or executable file, it still has the invalid version of 8.0.50608.0.  How do I get vs2005 to generate the correct version data for the manifest?  Did you redist the runtime files onto a development machine? Did you hack the file, and if so, what exactly did you insert?

    Tuesday, July 11, 2006 10:46 AM