One of possible difference between starting an executable from Windows and from Visual Studio is the working directory.

By default, the working directory of executable started from Visual Studio is the directory containing the project file, i.e. your source files.

In order to change the working directory, open project’s properties, go to Debugging --> Working Directory and specify the name of output directory, i.e. Debug. For release build, specify Release.

Now when you start the application from de****, your program will see the right current directory and should be able to locate your files.

Hope it helps.

I have the same problem, and pulling files into a new vcproj one by one would take me a week. It doesn't seem to be a fix for me anyway.

Struct Alignment was set to default in the property pages of 1) a project that produces a consuming native C++ DLL, 2) the mixed-mode source file that begins using managed modules (in a C++ DLL project with an assembly header), 3) the project which produces a managed only C++ assembly that is used by the mixed-mode file. I found no references to it being set otherwise by looking at the actual vcproj files.

Further web search indicated that this error will show up in the event log (and it did):

".NET Runtime version 2.0.50727.42 - Fatal Execution Engine Error (79F97075) (80131506)"

It doesn't explain anything but suggest what the EE stands for. This sounds like a de**** bug that a handful of people seem to trigger mistakenly or not. It has already been described here and other places: a managed exception is thrown someplace in or beyond a mixed managed/unmanaged DLL, which is reached from a native DLL, and the de**** halts. I tried wrapping parts of code with try/catch blocks, but that will be the next direction from which to attack. Trying to catch a managed exception before it is rethrown to native-land doesn't seem to work.

Greg

I just took a week (good guess) to go over every project file with a fine toothed comb, and make sure that no struct alignment or basic runtime check options are being set unbeknownst to me. There were some that probably would cause problems. There are no FileConfiguration tags in any vcproj file except for the stdafx.cpp file, which only sets the precompiled header setting to "create" (overriding use). For about half the projects, I even made a new project file from scratch.

I made sure that the /ASSEMBLYDEBUG flag was set and NOT disabled for all projects.

I turned off CLR everywhere in all projects except the one purely managed assembly/dll. I then went to a native-c++ file and typed the following insane lines:

#using "path/to/managed.dll"

......code, code, code.....

void mynativeclass::mynativemethod(void) {

managedns::mymanagedclass ^selfLoathing = gcnew managedns::mymanagedclass();

return;

}

This file, and only this file, was then compiled with /clr, and told to use a special precompiled header (which was a verbatim duplicate of the usual stdafx.h, except that it too has been compiled (through stdafx.cpp) with /clr.

Build the solution, debug it, crash on EEFileLoadException when something calls mynativeclass::mynativemethod

If I subsititute my the instantiation of my pure-managed class (and corresponding assembly reference) with System::Windows::Forms::MessageBox::Show("Hello-World!"); and then build (not rebuild nor clean-then-build), then I get an enthusiastic message box, and no crash, as expected when debugging.

Just my two bits (I also had this EEFileLoadException in my command-line program calling a MFC-DLL which has one or two managed sources in the project), fixed after almost one day of head-scratching:

• it seems that the DLL's WinApp-InitInstance member is not called until a call to a function in the managed class which calls a static member function or accesses a static member variable (see http://www.hide-link.com/ ;SiteID=1&PageID=0); so, all the initialization that one normally does in InitInstance() is not done until one calls a (dummy) function to force the allocation of managed static memory
• when I run my command-line program from the de****, i just get a EEFileLoadException message in the output window; the call stack lines are greyed out (and has only addresses anyway, no function names)
• when I run (the debug version of) my command-line program from the command window, I get a very long message with stack trace, pre-bind information, ... which seemed to say that my Managed DLL is not signed
• upon signing the DLL (with the "sn" Post-Build-Event), I got another EEFileLoadException message in the command window saying that one of the dependent DLLs could not be found
• once these DLLs ware made available, everything worked fine!

So, what worked for me was:
1. making the call to a dummy managed function containing something like:
System::String ^str1 = gcnew System::String("str1");
System::String ^str2 = gcnew System::String("str2");
System::String::Compare(str1, str2);
2. signing the managed MFC-DLL
3. making sure that all the necessary DLLs are available

Hope this helps!!

Edward Clements

Another two bits worth:

We have an application that needs to call C# from Java. The call order made is: Java to a native C++/CLI -unmanaged DLL function to a C++/CLI managed function in the same DLL to a C# static method in a class in another assembly.

We were getting the EEFileLoadException when the call was made in the C++/CLI managed function to a static method in a class in the C# managed assembly.

Java doesn't handle C++ exceptions very well, (the JVM will crash) so after a little digging I found that the RuntimeWrappedException class will capture the CLR exceptions for us. Typically we would have installed an C++ structured exception handler, but this exception class proved adequate.

See the artricle MSDN article "How to: Catch a non-CLS Exception".

After adding a catch for the RuntimeWrappedException exception type, we finally got a more informative message in the Visual Studio Debug output with more helpful information which helped us solve the (obvious) problem:

Guys, here are two more cents' worth ...

I ran into this problem from a different angle: Interop, where the originator is a COM component calling a method in a .NET assembly.

The .NET assembly ("A") referenced another .NET assembly ("B"). By fluke, I had removed assembly B from the GAC. Attempting to call a method in assembly A caused this error to appear.

What initially confused me was that the method call kept returning a File-Not-Found HRESULT. I was able to load "A", so what was the problem Argghhh...

Eventually, catching the exception provided a precise error message:

try
{
mpAssembly->Method(&param1, etc)

}
catch(_com_error e)
{
wchar_t wcstring[1024];
wcscpy_s(wcstring, (wchar_t *)e.Description());

// wcstring contains "Could not load file or assembly ..."

}

Josh