After you perform a major upgrade by using a Microsoft Windows Installer package, an assembly in the global assembly cache or SxS (side-by-side folder, \Windows\WinSxS\) is missing.

Back to the top

This problem occurs when the Windows Installer RemoveExistingProducts action is sequenced in a location that prevents appropriate reference counting of the assembly and that causes the premature removal of the assembly. The RemoveExistingProducts action is sequenced in the InstallExecuteSequence table in the Windows Installer package. This problem occurs when the RemoveExistingProducts action is sequenced so that the old product is removed before the new product is installed.

When an assembly is put into the global assembly cache, the assembly is renamed. Windows Installer cannot determine the correct name of the assembly. Windows Installer must rely on the Microsoft .NET Framework to manage the name.

When you perform a major upgrade by using a Windows Installer package, Windows Installer calls into the .NET Framework to test whether the assembly is already installed in the global assembly cache. If the .NET Framework returns yes, the component that contains the assembly in the major upgrade Windows Installer package is not allowed for installation. Next, the RemoveExistingProducts action runs and uninstalls the existing assembly in the global assembly cache. The RemoveExistingProducts action does this because the new product has not been registered as a client of the assembly and no other clients exist. Because the component in the major upgrade was not allowed for installation, the assembly is not reinstalled when the major upgrade installs the components.

If you resequence the RemoveExistingProducts action to schedule uninstallation of the old product after the new product is installed, the assembly will not be removed. The assembly will not be removed because the assembly now has an additional reference count from the new product. Therefore, even though the installation of the assembly is skipped for the major upgrade, the assembly still remains because another client references the assembly. The new product and the old product reference the assembly.

Note When an assembly is not located in the global assembly cache, no renaming occurs. The standard Windows Installer file versioning rules apply, and the component in the major upgrade is allowed for installation.

Back to the top

To work around this problem, use one of the following methods.

Back to the top

Method 1

Increase the AssemblyVersion attribute of the assembly that you are trying to install to create a side-by-side installation in the global assembly cache.

Back to the top

Method 2

Use a Windows Installer table-authoring tool to change the sequencing of the RemoveExistingProducts action in the InstallExecuteSequence table to occur after the InstallFinalize action. For example, use the Orca.exe database table editor for creating or editing Windows Installer packages.

Back to the top

You can create a Windows Installer package in a Setup and Deployment Projects project in Microsoft Visual Studio .NET. When the RemoveExistingProducts action is sequenced in this Windows Installer package, the default location of the RemoveExistingProducts action in the InstallExecuteSequence table causes the problem that is described in the "Symptoms" section.

For more information, visit the following Microsoft Developer Network (MSDN) Web sites:

Back to the top