Avoid Overwriting Files in Administrative Installations

Heath Stewart

Last June before the Microsoft .NET Framework 2.0 shipped, I discussed how during administrative installations some 64-bit files overwrote some 32-bit files and I provided a transform to fix the issue. I filed a bug and the issue was fixed before .NET 2.0 shipped. Later in the release cycle the Office Crash Reporting Tool, otherwise known as the Microsoft Application Error Reporting tool or “Dr. Watson”, was merged into the .NET 2.0 .msi files for each processor architecture and shipped.

Take a look at the component entries for different files with the same name for both x64 and x86 processor architectures. Paragraph characters (pilcrows) have been added to help delimit separate rows.

OfficeCrashReportingPolicyAmd_1033.F0DF3458_A845_11D3_8D0A_0050046416B9, {0C29705B-6507-4B80-AA5C-DD4683A83766}, WindowsINFFolder.F0DF3458_A845_11D3_8D0A_0050046416B9, 256, dw20.adm_0001_1033.F0DF3458_A845_11D3_8D0A_0050046416B9 ¶
OfficeCrashReportingPolicy_1033.D0DF3458_A845_11D3_8D0A_0050046416B9, {8CEA2451-A5C7-426B-91A7-ECCDD5E545F6}, WindowsINFFolder.D0DF3458_A845_11D3_8D0A_0050046416B9, 0, dw20.adm_1033.D0DF3458_A845_11D3_8D0A_0050046416B9 ¶

Note component directories for each component. While the first letter in bold is different, they resolve to the same directory as shown in the excerpt of the Directory table below. For good documentation on resolving directories in the Directory table, see Rob Mensching’s latest entry in his series about deciphering the Directory table.

WindowsINFFolder.D0DF3458_A845_11D3_8D0A_0050046416B9, WindowsFolder.D0DF3458_A845_11D3_8D0A_0050046416B9, INF ¶
WindowsINFFolder.F0DF3458_A845_11D3_8D0A_0050046416B9, WindowsFolder.F0DF3458_A845_11D3_8D0A_0050046416B9, INF ¶
WindowsFolder.D0DF3458_A845_11D3_8D0A_0050046416B9, TARGETDIR, WINDOWS ¶
WindowsFolder.F0DF3458_A845_11D3_8D0A_0050046416B9, TARGETDIR, WINDOWS ¶

These directories are set using type 51 custom actions as defined below, both called very early in the various sequence tables.

WindowsFolder.D0DF3458_A845_11D3_8D0A_0050046416B9, 51, WindowsFolder.D0DF3458_A845_11D3_8D0A_0050046416B9, [WindowsFolder] ¶
WindowsFolder.F0DF3458_A845_11D3_8D0A_0050046416B9, 51, WindowsFolder.F0DF3458_A845_11D3_8D0A_0050046416B9, [WindowsFolder] ¶

When you install the product, the files are installed correctly because the first component above uses component attribute msidbComponentAttributes64bit (256), which will cause the component to install into the 64-bit location, while the 32-bit component will be redirected into the 32-bit location under %WINDIR%SysWOW64.

However, when you perform an administrative installation using the 64-bit .msi file, files sequenced later in the File table will overwrite files destined for the same directory that are sequenced earlier in the File table. Component attributes are not a factor when performing an administrative installation. Keep this in mind when authoring your installation packages by directing files ultimately destined for different locations during client installations into different directories in the Directory table.

Different files with the same name but for different processor architectures aren’t the only cause of this issue, however. Managed assemblies to be installed into the Global Assembly Cache are also installed into directories as decided by fusion, such that during installation the Directory table doesn’t matter. If you’re installing satellite resource assemblies with the same name but different cultures, fusion will install the assemblies into the Global Assembly Cache correctly. But if you’re performing an administrative installation those resource assemblies cannot resolve to the same directory. Think of administrative installations as unzipping an archive. They are typically little more than that. In this case, consider authoring destination directories such that each satellite resource assembly installs into a sub-directory using the appropriate culture name.

To fix the reporting tool issues in 64-bit flavors of the .NET Framework 2.0 installation, download the attached archive, extract the transform, and use the transform during both the administrative installation and the client installation as shown below.

> copy /y dwfix.mst \SERVERSHARE
> NetFx64.exe /c:”msiexec /a netfx.msi TARGETDIR=””\SERVERSHARE“” TRANSFORMS=””\SERVERSHAREdwfix.mst”””
> msiexec /i \SERVERSHAREnetfx.msi /l*v install.log TRANSFORMS=”\SERVERSHAREdwfix.mst”

Heath Stewart Senior Software Engineer, Azure SDK

Follow