The point here is that you are using a multi package transaction. So
the whole Install Execute transaction can run either as "x86"
transaction or "x64" transaction if there are only "x64" pacakges in
the transaction but not as combined one where x64 packages are treated
as they should (e.g. targeting 'C:\Program Files\' folder). Windows
Installer now seems to make the "x64" packages compatible to x86
packages with the described result.
Read this issues a short time ago, think it was also in this mailing
list but don't find the link anymore.
In general I think as workaround you could separate the logic and use
a second transaction just for installing the x64 packages in your
bootstrapper.
Regards,
Tobias
2011/4/1 Douglas Mendizabal <doug...@asna.com>:
> I'm using an external UI to chain several msi files together. I have an
> ExternalUIHandler that is part of a WPF MVVM wizard application. Most of the
> msi files are 32bit ("Intel" platform) but one of them is a 64 bit ("x64"
> platform, let's call it "my-x64.msi") that contains both 32-bit and 64-bit
> components. The wizard app checks the operating system bitness and then
> makes a list of the msi files that will be installed, so that the x64 msi is
> only installed when running on a 64-bit OS.
>
> When I run the my-x64.msi by itself, the 64-bit components are correctly
> installed into C:\Program Files\... and the 32-bit components are installed
> into C:\Program Files (x86)\... However, when my-x64.msi is installed by the
> External UI, the Windows Installer service treats it like a 32-bit MSI and
> WIN64DUALFOLDERS hoses all components using ProgramFiles64Folder, so I end up
> with all components in the C:\Program Files (x86)\... folder.
>
> >From the MSI log when using the External UI:
>
> MSI (s) (9C:00) [16:00:24:038]: WIN64DUALFOLDERS: 'C:\Program Files (x86)\'
> will substitute 17 characters in 'C:\Program Files\' folder path. (mask
> argument = 0, the folder pair's iSwapAttrib member = 0).
>
> In the External UI, I'm using
>
> var installTransaction = new Transaction("myInstallTransaction",
> TransactionAttributes.None);
>
> to start a muti-package transaction. After that I'm using
>
> Installer.InstallProcut(pathToMsiString, propertiesString);
>
> for every MSI file, followed by
>
> installTransaction.Rollback();
>
> if any InstallProduct() call fails or is cancelled, or
>
> installTransaction.Commit();
>
> if they are all successful. Am I missing something else here? Or have I
> stumbled upon a bug in DTF?
>
> Thanks,
> Douglas M.
>
> ------------------------------------------------------------------------------
> Create and publish websites with WebMatrix
> Use the most popular FREE web apps or write code yourself;
> WebMatrix provides all the features you need to develop and
> publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
------------------------------------------------------------------------------
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
