Native dll built with /CLR flag containing a managed class - c++

Question

I have a old native MFC/c++ dll I have managed to get it compiled with /CLR flag.
Now I have added a managed C++/CLI class to the dll within a namaspace.
The header file is below, and the cpp file only has #include for the header file.
The native dll is a huge dll project with lot of un managed code, but it has only one managed c++ class like below.
When I add that dll as a reference to a .net winforms project I don't see that namespace / class, in the object browser,
and I get compile error for not finding the namespace "ShashiTest"
I am using Visual studio 2008.
Native dlls in mixed mode can not be added as reference to a managed project ?
Or am I missing something
Please help.
#pragma once
#using<mscorlib.dll>
#using<system.windows.forms.dll>
// Class derived from Forms
using namespace System::Windows::Forms;
using namespace System;
using namespace System::ComponentModel;
using namespace System::Collections;
using namespace System::Diagnostics;
using namespace System::Windows::Forms;
namespace ShashiTest {
/// <summary>
/// Summary for test
/// </summary>
public ref class test
{
public:
test(void)
{
};
void ShowMessage()
{
MessageBox::Show("Hello World");
}
};
}
When I simplified my problem..I created a fresh MFC dll and added a manged C++ class to it (same class as above) . Compiled with /CLR flag.
When I add this dll to winforms project and run it i get
System.BadImageFormatException. Any clue ?
However I see the class and the name space and winform project compiles fine unlike the problem I have the above.

Answer 1

System.BadImageFormatException is usually caused by having an AnyCPU .NET application reference a DLL containing 32-bit native code. You get an error when running on a 64-bit platform, because the AnyCPU application runs as 64-bit, and can't load the DLL. The fix for this is (easy) to mark the application as x86-only or (hard) to provide both 32-bit and 64-bit versions of all DLLs containing native code.
Of course, you could have some other problem. Checking your DLL with Red Gate Reflector as suggested by #cdleonard in the comments is a great next step. Or ILSpy, which is free.