32-bit CLR application on 64-bit system

Hello.

I'm trying to get working Debug version of our 32-bit CLR dll on a 64-bit
Server 2003, so far unsucessfully. I reduced the problem to not get working
*any* Debug 32-bit CLR application on a 64-bit system.

In VS2008 I created a new "CLR Console Application" project, and compiled it
*without* modifications. The 32-bit binary prints "Hello World" on a
32-system. But when I copy that binary to a 64-bit system, its Debug version
cannot be executed. The system replies with error "The system cannot execute
the specified program.". I have no idea where lies the problem. Can anyone
help me?

Details:
- Release version of the same HelloWorld application works fine.
- The problem hasn't disappear when I took a *clean* installation of Windows
Server 2003 R2 SP2 Standard x64 Edition. I installed .NET 2.0 SP1 (x64
version) and VC9 redistributable packages (x86 version; this installed the
release version, the debug version of CRT was copied from VS2008). *Nothing*
else was installed. Then again, the release version worked fine, the debug
version didn't execute.
- The HelloWorld application was compiled on a 32-bit VS2008 for (the
default) Win32 platform and .NET 2.0, and the linker target was for x86.
- On the x64 machine, the exact system response when executing the
release/debug versions is:

E:\temp>test.exe
Hello World

E:\temp>testd.exe
The system cannot execute the specified program.

- For the Debug version of the HelloWorld application, Dependency Walker
reports (apart to seemingly harmless errors) the following critical(?)
error:

Error: The Side-by-Side configuration information for
"E:\temp\testd.exe" contains errors. This application has failed to start
because the application configuration is incorrect.

The strange thing is that Dependency Walker shows no difference in
dependencies between release and debug versions (apart of dependency on the
release/debug versions of MSVC*.DLLs). And the Release version reports no
such error. See the attached image.
- I think that the other errors reported by Dependency Walker are harmless
because they are reported even for the working Release version of the
aplication:

Error: At least one module has an unresolved import due to a missing
export function in an implicitly dependent module.
Error: Modules with different CPU types were found.

- The manifest embedded in the Debug version of the test application is:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
manifestVersion="1.0">
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker"
uiAccess="false"></requestedExecutionLevel>
</requestedPrivileges>
</security>
</trustInfo>
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.VC90.DebugCRT"
version="9.0.21022.8" processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
</dependentAssembly>
</dependency>
</assembly>

For Release version it refers CRT instead of DebugCRT, the rest of the
manifest is identical.
- I'm aware that the debug versions of CRT libraries are not installed
automatically on x64 systems. That's why I copied them from VS2008 into the
application directory.
- Further information - if necessary - was discussed in the thread of the
same name in the microsoft.public.dotnet.framework.clr news-group. The
discussion there is probably ceased.

Thank you,

Martin.

 

Hello Martin,

Probably not much help but I develop with VS2008 on a Win7 x64 system so
I just made a default debug 32 bit CLR Hello World console app and it
worked just fine. However I don't use CLR at all so I don't know what
your problem is but surely it must be a missing dependency? Can you try
remote debugging your X64 box or does it not start at all?

This is probably not a good NG for dev questions, the folks here are
mostly system setup experts rather than developers.

Cheers
Doug Forster

 

Hooray!

Problem solved! The solution is in that it is not sufficient to copy
*content* of the Microsoft.VC90.DebugCRT into the application directory. It
is necessary to copy there the whole folder as a *subdirectory*.

Thanks to

http://www.tech-archive.net/Archive....public.vstudio.general/2008-11/msg00109.html

Martin.