32-bit CLR application on 64-bit system
Martin Plechsmid
I'm trying to get working our 32-bit CLR dll on a 64-bit Server 2003, so far
unsucessfully. I reduced the problem to get working *any* 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, it 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:
- I tried to compile the HelloWorld program both as Debug and Release, with
the same result.
- Dependency Walker says that the 32-bit program uses 32-bit MSVCR90.DLL and
MSVCM90.DLL (it has them copied in its directory), and depends on 64-bit
KERNEL32.DLL and MSCOREE.DLL (both with red colour). It repords the
following errors:
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.
I don't know where the first error comes from, Dependency Walker tree view
displays no problem (eg. the yellow question mark).
- On the 64-bit server we run a (non-CLR) MFC application, and it works
fine. Though the Dependency Walker reports the "Modules with different CPU
types were found" error too. Even on the KERNER32.DLL and many other DLLs.
It doesn't use MSCOREE.DLL though.
Thank you,
Martin.
Immo Landwerth
> I'm trying to get working our 32-bit CLR dll on a 64-bit Server 2003,
> so far unsucessfully.
>
> I reduced the problem to get working any 32-bit
> CLR application on a 64-bit system.
I guess you meant
| I reduced the problem to *not* get working any 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, it 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?
A few questions come to mind:
- Did you compile it with AnyCPU or x86/X64/Itanium settings?
- What .NET Framework are you using and what VS do you use to compile
it?
- In addition, are you sure you have the correct .NET Framework
installed on the machine?
If you are using VS 2008 and select .NET Framework 2.0 in the target
framework setting this actually means you are requiring .NET Framework
*SP1* (I say this because as far as I remember launching a .NET 2.0 SP1
on a system that does only have .NET 2.0 without SP1 the app crashes
with a strange error).
--
Immo Landwerth
Martin Plechsmid
I compiled it with the default settings, that is "Win32" platform, and the
linker target is for x86.
> - What .NET Framework are you using and what VS do you use to
> compile it?
The application is compiled for .NET 2.0 with VS2008.
> - In addition, are you sure you have the correct .NET Framework
> installed on the machine?
Yes, I'm sure. We had .NET 2.0 installed on the machine. As we had these
problems, we tried to install .NET 3.5. It didn't help, naturally.
> If you are using VS 2008 and select .NET Framework 2.0 in the target
> framework setting this actually means you are requiring .NET Framework
> *SP1* (I say this because as far as I remember launching a .NET 2.0 SP1
> on a system that does only have .NET 2.0 without SP1 the app crashes
> with a strange error).
I'll check that, thank you. Nevertheless, our applications do not crash,
they simply do not execute.
Thank you,
Martin.
Immo Landwerth
> I must correct my original post: release version works, the debug
> version still does not execute. (I probably made an error during
> testing.)
Probably the reason is that you are missing the assembly
Microsoft.VC90.DebugCRT.dll
Because it is referenced from the embedded manifest:
<assemblyIdentity type="win32"
name="Microsoft.VC90.DebugCRT"
version="9.0.21022.8"
processorArchitecture="x86"
publicKeyToken="1fc8b3b9a1e18e3b">
</assemblyIdentity>
The solution is decribed here:
http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/b2aacd05-
d9e9-4c6f-95f5-d6c005c9a5c6/
| Vcredist_x64 just contains the 64-bit release version of VC++ runtime
| library; it doesn�t contain the debug version of VC++ runtime
| library. Thus, to make your debug version application run on the
| target machine, you can either switch the Runtime library option from
| /MDd to /MTd during compilation or copy the debug version VC++
| runtime library to the deployed machine. You can find the debug
| version VC++ runtime library in the �redist� subdirectory of your
| VC++ installed directory.
Does this help?
--
Immo Landwerth
Immo Landwerth
> Probably the reason is that you are missing the assembly
>
> Microsoft.VC90.DebugCRT.dll
>
> Because it is referenced from the embedded manifest:
>
> <assemblyIdentity type="win32"
> name="Microsoft.VC90.DebugCRT"
> version="9.0.21022.8"
> processorArchitecture="x86"
> publicKeyToken="1fc8b3b9a1e18e3b">
> </assemblyIdentity>
Forget to mention that this is the reason why you do not see that
dependency from the Dependency Walker (depends.exe).
--
Immo Landwerth
Martin Plechsmid
>
> Microsoft.VC90.DebugCRT.dll
>
> Because it is referenced from the embedded manifest:
>
> <assemblyIdentity type="win32"
> name="Microsoft.VC90.DebugCRT"
> version="9.0.21022.8"
> processorArchitecture="x86"
> publicKeyToken="1fc8b3b9a1e18e3b">
> </assemblyIdentity>
Instead of having there Microsoft.VC90.DebugCRT.dll I have there
Microsoft.VC90.DebugCRT.manifest and the 3 related DLLs (MSVCM90D.DLL,
MSVCP90D.DLL and MSVCR90D.DLL). They are in the x86 version, and I copied
them from the <VC9.0>\VC\redist\Debug folder. (The x64 version didn't work
as the exe is 32-bit.)
Martin.
Immo Landwerth
> Instead of having there Microsoft.VC90.DebugCRT.dll I have there
> Microsoft.VC90.DebugCRT.manifest and the 3 related DLLs
> (MSVCM90D.DLL, MSVCP90D.DLL and MSVCR90D.DLL). They are in the x86
> version, and I copied them from the <VC9.0>\VC\redist\Debug folder.
> (The x64 version didn't work as the exe is 32-bit.)
Not sure if I understood you correctly: you have those files present
and it still does not work?
--
Immo Landwerth
Martin Plechsmid
> and it still does not work?
Yes. I have copied them in the directory with the CLR executable. When they
were missing, Dependency Walker showed that.
Martin.
Martin Plechsmid
Server 2003 R2 SP2 Standard x64 Edition. I installed .NET 2.0 SP1 (x64
version) and VC9 redistributable packages (x86 version; release version is
installed, debug version of CRT is copied from VS2008). *Nothing* else is
installed.
With this configuration, the CLR HelloWorld program (test.exe, testd.exe)
exhibits the same problematic behaviour as on the other x64 server. That is,
the Release version works, the Debug version cannot be executed. See my
other posts in this thread. Any suggestion?
Thank you,
Martin.
Jesse Houwing
Looks like you're missing the J# Redist package on the machine. It's a
separate download.
--
Jesse Houwing
jesse.houwing at sogeti.nl
Martin Plechsmid
> Looks like you're missing the J# Redist package on the machine. It's a
> separate download.
It might be, though I don't think it's the problem. At first, the release
version of the application is missing MSJAVA.DLL too, and the release
version works. At second, the dependency on MSJAVA.DLL is only delay-loaded,
which means - I think - that the DLL is loaded only when necessary. My
application does not use java. At third, I have MSJAVA.DLL neither on my
32-bit computer, and there the application executes too.
Thank you,
Martin.
Ben Voigt [C++ MVP]
"Martin Plechsmid" <Se...@No.Mail> wrote in message
news:eWud2AL...@TK2MSFTNGP02.phx.gbl...
xcopy deployment generally doesn't work for C++/CLI apps (this is expected
to change with VS2010).
There are some tweaks to the manifest needed to get app-local CRT working.
Google is your friend.
>
> Martin.
>
>
>
> __________ Information from ESET NOD32 Antivirus, version of virus
> signature database 4512 (20091015) __________
>
> The message was checked by ESET NOD32 Antivirus.
>
> http://www.eset.com
>
>
>
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4512 (20091015) __________
The message was checked by ESET NOD32 Antivirus.
Martin Plechsmid
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
And thank you all, especially to Ben Voigt, who was wrong with the xcopy,
but pointed me to the right direction.
Martin.
Ben Voigt [C++ MVP]
"Martin Plechsmid" <Se...@No.Mail> wrote in message
news:O5MZRGjT...@TK2MSFTNGP05.phx.gbl...
Ok, yeah, it's not that xcopy *can't* work with C++/CLI apps, it's that the
normal steps (put DLLs in the application directory) don't work. You have
to jump through hoops.
>
> Martin.
>
>