is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)

"Boris" <bo***@gtemail.netwrote in message news:op.txxivc1445fww6@burk...

>I have a mixed DLL (a managed DLL in C++ calling functions in other
unmanaged DLLs) which I can build successfully in Visual Studio 2005 but
can't reference as I get then immediately the error:

is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)

Trying to find out what that actually means I read something that VS2005
will build a 32-bit or 64-bit DLL depending on what platform is used. As
I'm running a 32-bit Windows XP on a x64 CPU from AMD (with a target
platform "Win32" in VS2005) does it mean the DLL created is 64-bit? Or do

If you're running 32-bit Windows, it is necessary that all your modules be
32-bit (or AnyCPU for MSIL), and I doubt the compiler would give you
anything else, regardless of your CPU.

Only when moving from 32-bit to 64-bit OS, you can run into some problems
because AnyCPU modules change automatically because they see the 64-bit .NET
installed, and then your 32-bit native DLLs break.

On Tue, 04 Sep 2007 19:19:48 +0300, Ben Voigt [C++ MVP]
<rb*@nospam.nospamwrote:

[...]If you aren't running XP 64-bit, then you don't have .NET 64-bit
and no
issues there.

Yes, only a 32-bit XP here.

Are you opening a mixed exe? For pure MSIL assemblies, you can
reference a
dll or exe. For mixed assemblies, you can only reference a dll, the exe
has
relocations disabled and some other optimizations that mean it MUST be
the
main program.

Yes, it's only a DLL. As I said the code was originally used to build a
DLL in VS2003 which worked fine. Meanwhile I tried to build the same code
(with Managed C++) in VS2005 and in another project with code converted to
C++/CLI - both doesn't work (or to be more precise: building works but not
referencing). As the error message doesn't contain any details I wonder if
there is anything else I can do except removing code, rebuilding the DLL
and checking if it can be referenced then. That would help at least to
find out which part of the code causes the problem?

Boris

"Boris" <bo***@gtemail.netwrote in message
news:op***************@burk.mshome.net...

On Tue, 04 Sep 2007 19:19:48 +0300, Ben Voigt [C++ MVP]
<rb*@nospam.nospamwrote:

>[...]If you aren't running XP 64-bit, then you don't have .NET 64-bit
and no
issues there.

Yes, only a 32-bit XP here.

>Are you opening a mixed exe? For pure MSIL assemblies, you can
reference a
dll or exe. For mixed assemblies, you can only reference a dll, the exe
has
relocations disabled and some other optimizations that mean it MUST be
the
main program.

Yes, it's only a DLL. As I said the code was originally used to build a
DLL in VS2003 which worked fine. Meanwhile I tried to build the same code
(with Managed C++) in VS2005 and in another project with code converted to
C++/CLI - both doesn't work (or to be more precise: building works but not
referencing). As the error message doesn't contain any details I wonder if
there is anything else I can do except removing code, rebuilding the DLL
and checking if it can be referenced then. That would help at least to
find out which part of the code causes the problem?

Any chance you're trying to use a reference to a .NET 2.0 assembly from a
..NET 1.x application? Check System::Environment::Version in your main
application.

On Thu, 06 Sep 2007 04:46:44 +0300, Ben Voigt [C++ MVP]
<rb*@nospam.nospamwrote:

[...]Can you post the complete stack trace of the exception? Turn on
first-chance exception debugging (Debug Exceptions -set that
exception
type to "thrown") as well, you may get better traces.

The purpose of this is to look up the code in .NET Reflector and see
under
what conditions the error is created... but Exception from HRESULT
strongly
suggests nothing will be gained there.

Unfortunately you are right: Throwing System.BadImageFormatException and
the Win32 exception 0x800700C1 didn't reveal any details.

Have you changed manifest options at all? Perhaps selected static use of
runtime libraries (not compatible with .NET)?

All options in the C/C++ property page are set to default. In the linker
property page I had to add an additional dependency to an unmanaged
library from a third-party vendor (something I had to do for the VS2003
solution though, too). The Manifest Tool property page remained untouched.
Comparing the options with the VS2003 solution I see that I had added
additional dependencies to msvcrt(d).lib and mscoree.lib. If I'm not
mistaken they were required to fix the Mixed DLL problem in VS2003/.NET
1.1 and are not needed anymore for VS2005 solutions?

Can .NET Reflector load the C++/CLI DLL?

Yes, that works. I can also use the class browser in VS2005.

Thanks for your help so far,
Boris

On Thu, 06 Sep 2007 09:20:04 +0300, Boris <bo***@gtemail.netwrote:

[...]

I've been throwing everything away except one class which has only an
empty constructor. When I build the .NET DLL now there is basically no
code inside - but the problem remains.

Going once again through the project configuration I would guess that the
dependency on an unmanaged library causes the problem. Although the .NET
DLL currently does not call any functions in the unmanaged DLLs it depends
on I still have to add a dependency to the project configuration although
this library is only used by the unmanaged DLLs the .NET DLL depends on.
If I don't add the dependency I get "unresolved token" and "unresolved
extern symbol" errors. If I do the errors disappear and only a warning
"unresolved typeref token ...; image may not run" remains. That said I do
get a DLL then but it seems to be faulty.

Although I don't know if I'm on the right track I wonder if there is
anything to take care of when a managed DLL depends on an unmanaged
library?

Boris

On Thu, 06 Sep 2007 09:20:04 +0300, Boris <bo***@gtemail.netwrote:

[...]

I found out what causes the problem (which doesn't mean though that I have
an idea how to solve it) and can now provide a reproducable test case. You
must have installed Boost 1.34.1 (see http://www.boost.org/) and add this
code to a C++/CLI project:

#pragma once
#include <boost/thread/mutex.hpp>

#using <mscorlib.dll>
using namespace System;

namespace MyNamespace
{
public ref class MyClass
{
public:
MyClass() { }
};
}

Including the header boost/thread/mutex.hpp makes it impossible to load
the DLL (yes, including is enough - no need to use any code from that
header). I probably have to submit a bug report to Boost (or Microsoft?).

Boris

"Boris" <bo***@gtemail.netwrote in message
news:op***************@burk.mshome.net...

On Thu, 06 Sep 2007 09:20:04 +0300, Boris <bo***@gtemail.netwrote:

>[...]

I found out what causes the problem (which doesn't mean though that I have
an idea how to solve it) and can now provide a reproducable test case. You
must have installed Boost 1.34.1 (see http://www.boost.org/) and add this
code to a C++/CLI project:

#pragma once
#include <boost/thread/mutex.hpp>

#using <mscorlib.dll>
using namespace System;

namespace MyNamespace
{
public ref class MyClass
{
public:
MyClass() { }
};
}

Including the header boost/thread/mutex.hpp makes it impossible to load
the DLL (yes, including is enough - no need to use any code from that
header). I probably have to submit a bug report to Boost (or Microsoft?).

Try

#pragma managed(push, off)
#pragma managed(pop)

around the #includes for boost headers

>
Boris