About Windows Installer, the .NET Framework, and Visual Studio.
If you've tried to install the .NET Framework 2.0 Beta 2 redistributable for either ia64 or x64 from an administrative installation point, you might've seen an error like the following:
While investigating patching scenarios for 64-bit SKUs I found that for source extraction and administrative installs the 32- and 64-bit files map to the same paths. This, unfortunately, shipped in beta 2. The problem this causes is that a 64-bit call to LoadLibrary will fail to load a 32-bit DLL such as mscoree.dll. Only the 64-bit libraries wow64.dll, wow64win.dll, wow64cpu.dll, and ntdll.dll can be loaded into a 32-bit process, so the error dialog above or a similar error is displayed. You might also find the following log lines in your log file:
06/07/05 14:00:40 DDSet_Status: LANGID: 103306/07/05 14:00:40 DDSet_Entry: InstallAssembly started06/07/05 14:00:40 DDSet_Status: CustomActionData: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50215\Microsoft.VisualBasic.Vsa.dll;2867206/07/05 14:00:40 DDSet_Status: Loading mscoree.dll06/07/05 14:00:40 DDSet_Error: Error occurred while initializing fusion. Unable to load mscoree.dll. System error: %1 is not a valid Win32 application.MSI (c) (14:14) [14:00:40:822]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell DlgError 25002.Error occurred while initializing fusion. Unable to load mscoree.dll. System error: %1 is not a valid Win32 application.MSI (s) (70!40) [14:00:57:087]: Product: Microsoft .NET Framework 2.0 Beta 2 (x64) -- Error 25002.Error occurred while initializing fusion. Unable to load mscoree.dll. System error: %1 is not a valid Win32 application.06/07/05 14:00:57 DDSet_CARetVal: 2500206/07/05 14:00:57 DDSet_Exit: InstallAssembly ended with return value 1603Action ended 14:00:57: InstallFinalize. Return value 3.
The problem is that when extracting source files as we do for our patch build system, or creating an administrative installation no custom actions are run. Many custom actions are used to set directory paths for components that are provided by merge modules (MSMs), which is the majority of files. Since the 32-bit files must be installed to support 32-bit applications, the x86 mondo MSM is consumed which uses the same source and destination directory names.
To enable administrative deployment for beta 2, you must either modify the MSI or create a transform, which I recommend. This gives you flexibility without changing the target MSI.
There are several ways of creating transforms, from programming against the Windows Installer APIs or using the object model to using Orca from the Windows Installer SDK, part of the Platform SDK. To install Orca - a graphical tool for editing MSIs, MSPs, or MSMs; and creating transforms - you must install Orca.msi in the Bin sub-directory of your Platform SDK installation root.
To create the transform, follow the steps below. You can also simply skip the steps and download and extract pathfix.mst.
When creating an administrative installation now, pass TRANSFORMS="<path>\pathfix.mst" to the command line and copy the transform to the target directory like in the following example:
msiexec /a netfx.msi /l*v netfx_admin.log TARGETDIR=\\SERVER\SHARE TRANSFORMS=pathfix.mst
copy pathfix.mst \\SERVER\SHARE
To deploy the application, you must also specify the transform when installing like in the following example:
msiexec /i \\SERVER\SHARE\netfx.msi TRANSFORMS=\\SERVER\SHARE\pathfix.mst
This bug has been fixed in later builds of 2.0.
Resources for authoring 64-bit Windows Installer packages and merge modules.