Unable to load class library

Unable to load class library

• Gareth Berry

  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
  
  

• arn0

  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
  
  

• Deemad

  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
  

• EricSS

  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
  

• Phenom

  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
  
  
  

• mutantbc

  I don't get a error message, the program runs fine.
  
  

• LuckyMe

  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.
  

• LJ_1102

  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
  

• arv_6363

  >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

  
  

• Bosphorus

  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.

  
  
  

• DrScheme

  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.

   

  
  
  

• adfm

  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
  

• AnaD

  Yes it's on Win32 (XP SP2)
  

• -JFo

  Maybe, I'm using the Final Version of VS2005.

  
  
  
• Unable to load class library