.NET Framework - compiling 32bit application (x86) in VS2008 (VC2008) on Vista 64bit (x64)

Asked By googl on 01-Nov-08 04:29 AM
Hi All

I compiled application in VS2008 on Vista x64 using Win32 platform set
in Configuration Manager. This application makes use of dynamic
runtime (crt) and needs a couple of dll files. I run Dependency Walker
to find out what dlls are needed and here is the list:

The first problem:

All three msvc* dlls are not found in the system by Dependency Walker
with an error
The question is why? I see there are seven versions of for example
msvcp90.dll file on my system:
C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\redist

The second problem:

All other dlls from the list (these are found by Depedency Walker) are
marked as 64bit.
Why does VS link my 32bit application with 64bit dlls?

I tried to run this application on 32bit Vista and got this error:

configuration is incorrect. Please see the application event log for
more detail."

The application event log had this:

Dependent Assembly
could not be found. Please use sxstrace.exe for detailed diagnosis."

It looks like the system looks for the x86 assembly and not the x64.
I'm lost.

Any suggestions?

Piotr Dobrogost

Ivan Kolev replied on 05-Nov-08 10:35 PM
I noticed the same today and found your post. The problem is that you
are running the 64-bit version of Dependency Walker for a 32-bit
module. It turns out the correct thing to do is to run the 32-bit
Depends for 32-bit modules. Although when I did that, I still get a
strange error, that MSVCP90D.DLL cannot find MSVCR90D.DLL (but I get
the same error under WinXP32, so I guess it's a Depends's quirk). And
my application is working properly (under Vista64 and WinXP32).

Sure, it's compiled for Win32, so it looks for the x86 version of the
CRT - isn't that what you need?
David Connet replied on 05-Nov-08 11:08 AM
Ivan Kolev <ikolev@gmail.com> wrote in

I'll bet I know what's going on here - you (OP) have VC9+SP1 right? Well
the default behavior says use v9.0.21022.8 of the dll. SP1 is
9.0.30729.1. So your code is linked to 30729, but the manifest says load
21022. (If you actually install the runtime dlls, then the registry is
setup to redirect 21022 to 30729) I was distributing (localapp) the 30729
version of MFC/RTL, and ran into this. It took a long time and many
DLL-hell to this - at least you could figure it out!

Now you need to know the super-secret magic word. Ready...?
intermediate output directory - and make sure it's what you want. To get
just the single 20729 entry, you'll need to recompile _everything_ with
that flag set - all dlls, static libs, etc...

Note, if you use 3rdParty dlls that have been compiled using 21022, you
will have multiple entries - then the only workaround I know of is it
actually install the redist so the SxS stuff is setup right. Or
statically link (for my open source project, that's what I did).

Dave Connet