Microsoft KB Archive/934388

= An .installstate file is not removed after you uninstall a .NET Framework 2.0-based application =

Article ID: 934388

Article Last Modified on 12/3/2007

-

APPLIES TO


 * Microsoft .NET Framework 2.0

-



SYMPTOMS
After you uninstall a Microsoft .NET Framework 2.0-based application, an .installstate file is not removed.

This problem occurs if the following conditions are true:
 * The assembly is copied to the global assembly cache and to a folder.
 * The assembly is not copied to a different folder.



CAUSE
This issue occurs because of a problem in a custom action. If you use the Assembly.LoadFrom method to load an assembly in the Microsoft .NET Framework 1.1, the Location property returns the path of the folder that you sent to the LoadFrom method. This behavior occurs even if the assembly is ultimately loaded from the global assembly cache.

However, if you use the Assembly.LoadFrom method to load an assembly in the .NET Framework 2.0, the Location property returns the location of the assembly that is ultimately loaded. When you install the application, the assembly is not yet in the global assembly cache when the custom action runs. Therefore, the assembly is loaded from the folder on the hard disk. This occurs because of the way that the Microsoft Windows Installer file works. Additionally, the Location property returns the path of the folder. The .installstate file is also in the folder.

When you uninstall a .NET Framework 2.0-based application, the assembly is in the global assembly cache. Therefore, the Assembly.LoadFrom method loads the assembly from the global assembly cache. Additionally, the Location property returns a location of the global assembly cache. This location does not contain the .installstate file. Therefore, the .installstate file cannot be found. This causes the problem that is mentioned in the &quot;Symptoms&quot; section.



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

Method 1
Do not use a managed custom action. A custom action may cause this problem. In particular, a managed custom action may cause this problem.

Method 2
Follow these steps:
 * 1) Put all the custom action code in a different assembly.
 * 2) Do not copy the assembly that is mentioned in step 1 to the global assembly cache.

Keywords: kbtshoot kbprb KB934388

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.