.NET Framework - x64 Vista install of MSI failure

Asked By dhmot

04-Sep-09 11:44 AM

Hello,

I am having problems installing an MSI I created with VS 2008 (with or
without SP1) onto an x64 Vista SP1 or SP2 system.  Specifically, I get the
following side-by-side error when the package attempts to execute my
CustomAction routine on installation:

Dependent Assembly
Microsoft.VC90.CRT,processorArchitecture="amd64",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8" could not be found

However, this file
(Microsoft_VC90_CRT_x64.50FC30FE_9758_3B08_B886_7BAABC047B61 &
policy_9_0_Microsoft_VC90_CRT_x64.D8FD5D7A_D7AD_3E2F_9ACB_44D8D43BD919) is in
my Installation project and seems to be present in the MSI when I check the
MSI via Orca.  This MSI installs successfully on x64 XP.  A similar MSI built
for Win32 installs successfully on both XP and Vista.  (FYI: There are
several drivers in this MSI and it was much easier to create two MSIs rather
than one MSI with Win32 & x64).

The only Vista versus XP differences I can find in Orca is in the
for the MSMs.  There are two versions: an "uplevel" and a "downlevel" version
of the MSMs.  The uplevel goes to Vista (VersionNT >= 600) while the
downlevel goes to XP (VersionNT < 600).  The XP version also has a
downlevel_manifest.  There is no corresponding uplevel_manifest.  However,
I am not convinced this is the problem because the Win32 package looks the
same.

I realize I could probably fix this by simply installing the VS
redistributables on the x64 Vista system.  However, I also realize that is
not the correct solution - I do not want an end user of an x64 Vista system
to have to install another package just to get my MSI to install.  I could
also probably statically link in the stuff that I needed, but that is also not
really a correct solution.

I have kind of hit a dead end with my knowledge.  How should I go about trying
to fix this?

Thanks,
Michael

04-Sep-09 12:59 PM

Vista installs the CRT to SxS in the same way that assemblies to the GAC
have always been imstalled by MSI, using the .NET Fusion interfaces. These
have the unfortunate effect that the file is not actually available until
the Commit phase of the install, and this has broken pretty much every
install that used C++ merge modules and runs code (or starts a service) that
depended on them. You might find that a Commit custom action works because
by this time (InstallFinalize) the files are available.

Static linking is another choice, as is installing the C++ runtime
beforehand, as you mentioned.

--
Phil Wilson
The Definitive Guide to Windows Installer
http://www.apress.com/book/view/1590592972

04-Sep-09 01:43 PM

Phil,

I modified my MSI to run the install custom action during the commit phase
as per your suggestion.  Since I was already performing the "install" during
the commit phase on upgrade, this was no major change.  The package
successfully installed.

I will monitor this thread for a while to see if there is another solution, as
there are possible corner cases where the install could fail.  However, I
prefer your solution to the other two I mentioned (statically linking and
installing the redistributables).

Thanks,
Michael