{"id":3143,"date":"2005-06-07T18:53:00","date_gmt":"2005-06-07T18:53:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/heaths\/2005\/06\/07\/how-to-fix-administrative-deployment-for-64-bit-net-framework-redistributables\/"},"modified":"2018-09-06T06:02:42","modified_gmt":"2018-09-06T06:02:42","slug":"how-to-fix-administrative-deployment-for-64-bit-net-framework-redistributables","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/setup\/how-to-fix-administrative-deployment-for-64-bit-net-framework-redistributables\/","title":{"rendered":"How to Fix Administrative Deployment for 64-bit .NET Framework Redistributables"},"content":{"rendered":"

If you’ve tried to install the .NET Framework 2.0 Beta 2 redistributable for either ia64<\/a> or x64<\/a> from an administrative installation point, you might’ve seen an error like the following:<\/p>\n

\"mscoree<\/p>\n

While investigating<\/a> 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<\/code> will fail to load a 32-bit DLL such as mscoree.dll<\/i>. Only the 64-bit libraries wow64.dll<\/i>, wow64win.dll<\/i>, wow64cpu.dll<\/i>, and ntdll.dll<\/i> 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:<\/p>\n

06\/07\/05 14:00:40 DDSet_Status: LANGID: 1033
06\/07\/05 14:00:40 DDSet_Entry: InstallAssembly started
06\/07\/05 14:00:40 DDSet_Status: CustomActionData: C:WINDOWSMicrosoft.NETFrameworkv2.0.50215Microsoft.VisualBasic.Vsa.dll;28672
06\/07\/05 14:00:40 DDSet_Status: Loading mscoree.dll
06\/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.<\/p>\n

MSI (c) (14:14) [14:00:40:822]: Font created. Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg<\/p>\n

Error 25002.Error occurred while initializing fusion. Unable to load mscoree.dll. System error: %1 is not a valid Win32 application.<\/p>\n

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.<\/p>\n

06\/07\/05 14:00:57 DDSet_CARetVal: 25002
06\/07\/05 14:00:57 DDSet_Exit: InstallAssembly ended with return value 1603
Action ended 14:00:57: InstallFinalize. Return value 3.<\/font><\/p>\n

The problem is that when extracting source files as we do for our patch build system, or creating an administrative installation<\/a> 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.<\/p>\n

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.<\/p>\n

There are several ways of creating transforms, from programming against the Windows Installer APIs<\/a> or using the object model<\/a> to using Orca from the Windows Installer SDK, part of the Platform SDK<\/a>. To install Orca – a graphical tool for editing MSIs, MSPs, or MSMs; and creating transforms – you must install Orca.msi<\/i> in the Bin<\/i> sub-directory of your Platform SDK installation root.<\/p>\n

To create the transform, follow the steps below. You can also simply skip the steps and download<\/a> and extract pathfix.mst<\/i>.<\/p>\n

    \n
  1. Download either or both of the 64-bit redistributables you want to deploy:\n