Managed C++/CLI static linked with native library

Hi, All,

I am trying to expose functions in native c++ through managed c++/CLI to C#. when I set the Target platform to "Any CPU", I got the error

Unable to load file or assembly,....

Then, I switch Target Platform to x86, I got another different error:

is not a valid win32 application.

My environment is visual studio 2008 under windows 7 64-bit. I suspect it is because some dependency is 64-bit.

But, how can find out what really causes this problem?

Any suggestion will be appreciated. Thanks in advance.

What is native library target platform? And what happens if you set C++/CLI project target platform to x64?

Yes, that is one thing I tried to do. I am able to set target platform for both C# and managed C++/CLI, but I did not find Target Platform option for native C++ progects.

Actually, I found it.

For C#, Managed C++ and native C++, all target platform/machine are x86.

The native C++ is used as a static library.

I did this under 32bit XP without any problem.

I don't have a clear idea regarding how to handle 32bit under 64bit OS.

Target platform should be the same in all three projects. When Visual Studio is installed, ensure that both 32 and 64 bit compiler and linker are installed. You should be able to build and execute both 32 and 64 configurations on 64 bit OS. On 32 bit OS, it should be possible to build both 32 and 64 configurations, but only 32 bit configuration may be executed.
I don't think that it is possible to use "Any CPU" in this case, because unmanaged library doesn't have this option and cannot be dynamically JIT-compiled, depending on current OS.

The problem lies with Windows, not with the build.

When windows runs a process it marks it as either 64-bit or 32-bit.

Windows cannot load a 32-bit dll into a 64-bit process, or vice versa.

If you build a .NET application (doesn't matter what type - C++/CLI, C# etc) as 'Any Cpu' then on 64-bit systems this will run as a 64-bit application.

All .NET assemblies which are loaded from that point onwards will be compiled to 64-bit.

However if it tries to load a 32-bit native dll it will fail - 32-bit dlls cannot be loaded into 64-bit applications.

So if you're using 32-bit native dlls from a .NET application you have to always set the application to being 'x86'.

Darwen.