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.
Martin Plechsmid wrote: > 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).
> - Did you compile it with AnyCPU or x86/X64/Itanium settings?
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.
Martin Plechsmid wrote: > 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:
| 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.
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 Plechsmid wrote: > 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?
I tried the same CLR HelloWorld program on 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; 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?
> 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.
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*.
> 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*.
> And thank you all, especially to Ben Voigt, who was wrong with the xcopy, > but pointed me to the right direction.
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.
|
