microsoft.public.dotnet.framework.clr Google Group

Re: 32-bit CLR application on 64-bit system - solved!

bvo...@newsgroup.nospam (Ben Voigt [C++ MVP]) — Fri, 10 Oct 2009 16:44:13 UT

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.

Re: 32-bit CLR application on 64-bit system - solved!

s...@no.mail (Martin Plechsmid) — Fri, 10 Oct 2009 07:23:27 UT

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
[link]

Re: AppDomains and native DLLs

bvo...@newsgroup.nospam (Ben Voigt [C++ MVP]) — Fri, 10 Oct 2009 01:17:45 UT

oh gee, you already said what I did.... I was thinking of your statement in
terms of named kernel objects, but those are session-global, not
process-global.
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4512 (20091015) __________
The message was checked by ESET NOD32 Antivirus.

Re: AppDomains and native DLLs

bvo...@newsgroup.nospam (Ben Voigt [C++ MVP]) — Fri, 10 Oct 2009 01:14:40 UT

And if the DLLs import another DLL that uses global data, you'll still end
up with data sharing across app-domains no matter what you do (short of
recompiling all dependencies with /clr and app-domain awareness).
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4512 (20091015) __________

Re: 32-bit CLR application on 64-bit system - more info

bvo...@newsgroup.nospam (Ben Voigt [C++ MVP]) — Fri, 10 Oct 2009 01:11:00 UT

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.
__________ Information from ESET NOD32 Antivirus, version of virus signature database 4512 (20091015) __________

Re: 32-bit CLR application on 64-bit system - NonDelayed screenshot

s...@no.mail (Martin Plechsmid) — Wed, 10 Oct 2009 13:08:53 UT

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

Re: 32-bit CLR application on 64-bit system - NonDelayed screenshot

jesse.houw...@newsgroup.nospam (Jesse Houwing) — Wed, 10 Oct 2009 12:29:24 UT

* Martin Plechsmid wrote, On 14-10-2009 10:28:
Looks like you're missing the J# Redist package on the machine. It's a
separate download.

Re: 32-bit CLR application on 64-bit system - further info

s...@no.mail (Martin Plechsmid) — Wed, 10 Oct 2009 11:30:30 UT

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.

Re: 32-bit CLR application on 64-bit system - more info

s...@no.mail (Martin Plechsmid) — Wed, 10 Oct 2009 09:25:02 UT

Yes. I have copied them in the directory with the CLR executable. When they
were missing, Dependency Walker showed that.
Martin.

Re: 32-bit CLR application on 64-bit system - more info

mail_igno...@web.de (Immo Landwerth) — Wed, 10 Oct 2009 09:17:38 UT

Not sure if I understood you correctly: you have those files present
and it still does not work?

Re: 32-bit CLR application on 64-bit system - more info

s...@no.mail (Martin Plechsmid) — Wed, 10 Oct 2009 09:08:29 UT

Instead of having there Microsoft.VC90.DebugCRT.dll I have there
Microsoft.VC90.DebugCRT.manife st 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.)

Re: 32-bit CLR application on 64-bit system - more info

mail_igno...@web.de (Immo Landwerth) — Wed, 10 Oct 2009 08:47:16 UT

Forget to mention that this is the reason why you do not see that
dependency from the Dependency Walker (depends.exe).

Re: 32-bit CLR application on 64-bit system - more info

mail_igno...@web.de (Immo Landwerth) — Wed, 10 Oct 2009 08:43:28 UT

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"

Re: 32-bit CLR application on 64-bit system

do....@mail.me (Martin Plechsmid) — Tue, 10 Oct 2009 19:57:50 UT

I compiled it with the default settings, that is "Win32" platform, and the
linker target is for x86.
The application is compiled for .NET 2.0 with VS2008.
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.
I'll check that, thank you. Nevertheless, our applications do not crash,

Re: 32-bit CLR application on 64-bit system

mail_igno...@web.de (Immo Landwerth) — Tue, 10 Oct 2009 14:42:35 UT

I guess you meant
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