Udostępnij za pośrednictwem

Why can't I uninstall my assembly?

  • Artykuł

When installing an assembly to the GAC, Fusion provides a mechanism for the installer to specify a traced reference count on the assembly being installed. The idea is that if the same assembly is installed multiple times by different clients, the assembly is not removed until all of the clients that installed the assembly have explicitly requested uninstall. Without such a feature, you could run into scenarios where assemblies are prematurely uninstalled. For example: two applications install the same shared assembly to the GAC; one application is uninstalled, and the shared assembly is removed even though another app still needs it.

The reference counts Fusion provides are called “traced” reference counts, because unlike COM reference counts, which simply record the number of outstanding clients, an installer is allowed to specify information identifying who needs the particular assembly. There are different kinds of traced reference counts that an installer can provide, such as a filepath, or an opaque string that is installer-specified. Gacutil allows you to specify traced reference counts in an install command-line via the /r option.

You can read more about traced reference counts in this gacutil MSDN document. There is also information about traced reference count in our support article describing the unmanaged Fusion API.

When you install your assembly using MSI (which is the recommended approach for retail installs), there is no need to specify a traced reference count for your assembly, because MSI has its own internal reference counting mechanism. When Fusion is asked to uninstall an assembly from the GAC, it will check if there are any outstanding traced reference counts. If there aren't any traced reference counts, Fusion will call a Windows Installer API to determine whether or not MSI holds a reference on the assembly. If any reference count (traced reference count, or MSI reference count) exists, the assembly will not be uninstalled.

If you try to uninstall an assembly in the GAC using “gacutil -u”, you may see a message indicating that some traced reference count remains on the assembly, and gacutil will output the information about the pending traced reference count. In order to uninstall it, you must remove all the traced reference counts. For MSI-installed assemblies, this is only possible by uninstalling the MSI package that installed the assembly via Add/Remove programs.

Some customers have reported unusual cases where an assembly installed into the GAC via gacutil without a traced reference count, can later not be uninstalled via “gacutil -u“. When the uninstall is attempted, the following message appears:

Unable to uninstall: assembly is required by one or more applications Pending references:

SCHEME: <WINDOWS_INSTALLER> ID: <MSI> DESCRIPTION:<Windows Installer>

This message is informing the user that Fusion thinks that Windows Installer holds a reference count on the assembly, yet this information is clearly wrong because the assembly was never installed via MSI.

If you encounter this problem, it is very likely that you have run into an odd MSI registry corruption (at the time of this writing, the cause is unknown). Without getting into a long-winded explanation of how this registry corruption eventually results in the error message above, the common cause of this is a bogus default value set under one (or both) of the below registry keys:

[HKCU\Software\Microsoft\Installer\Assemblies\Global]   

[HKLM\SOFTWARE\Classes\Installer\Assemblies\Global]

If these keys are not empty (e.g. they contain a MSI descriptor value), then you have hit this situation, and you should be able to fix the problem by clearing the default value. I can't guarantee that this will always work, but it has definitely been our experience that this is the most common source of this problem.

(This tip comes courtesy of our resident MSI expert on the Fusion team, Roberto Sciore).

Comments

  • Anonymous
    December 10, 2003
    Alan -- thank you for this tip. I recently came across this problem myself and found the same solution, but I wasn't sure if it was a "kosher" operation. Thank you for verifying my suspicions from a Fusion team member.
  • Anonymous
    December 10, 2003
    Ditto, thanks.
  • Anonymous
    December 10, 2003
    Isn't it so that MSI is NOT the right choice for this because of this odd bug? IMHO when using MSI (it's easy to use, so why not use it) and you want to install to the GAC: shell out and run gacutil.exe to install the assembly. Requires more work, but you can be sure it will uninstall.
  • Anonymous
    December 10, 2003
    Actually, the cause is not so unknown at all! One of our coworkers discovered this problem was consistently triggered by the MSN Messenger 6.0 installation!
  • Anonymous
    December 10, 2003
    We've reproduced the MSN Messenger behavior here at our company.


    I've uninstalled that and installed Trillian instead [which can access MSN Messenger contacts]
  • Anonymous
    December 11, 2003
    Thanks for all the comments. I'll take the information you've provided about MSN Messenger 6.0 creating the corrupt MSI registry problem to the Windows Installer team so we can investigate further.

    Frans, MSI is definitely the recommended way to install your assemblies (particularly in retail environments). The bug being described is a little orthogonal to choosing MSI as an installer; even if you shell out to gacutil.exe to install, doesn't guarantee the ability to uninstall (because the bug affects all uninstalls).

    I'll be sure to let you all know when we get more information on this issue.
  • Anonymous
    January 07, 2004
    I have this same problem but both keys contain no values...
  • Anonymous
    January 07, 2004
    It seems that (in Win2KPro) executing the following froma commandline does the trick: rd /s <Assembly Name>
  • Anonymous
    January 07, 2004
    Maybe I should clarify... the "rd /s <Assembly Name>" should be executed from C:WINNTassemblyGAC
  • Anonymous
    February 16, 2004
    The comment has been removed
  • Anonymous
    February 16, 2004
    Success.

    After a restart and deleting each file manually I was able to remove the files.
  • Anonymous
    February 18, 2004
    Thanks It Works Really Good Solution
  • Anonymous
    February 18, 2004
    Success
  • Anonymous
    March 01, 2004
    Alan - Thanks for this - I had this problem, and your advice was very helpful.
  • Anonymous
    March 25, 2004
    My registry keys where empty, so i have to delete the files manualy... in case someone is wondering which files... i deleted all files in c:[Windows dir]assemblygac[assembly name].

    To delete all this i have to use DOS...

    Thanxs Alan.
  • Anonymous
    March 25, 2004
    I have been having the same problem and have not been able to fix it with the methods above. Firstly, can I check that I've tried the right thing: the [HKCUSoftwareMicrosoftInstallerAssembliesGlobal] key does not exist on my machine (there is no "Installer" in the HKCUSoftwareMicrosoft... part of the registry); the [HKLMSOFTWAREClassesInstallerAssembliesGlobal] does, and has a whole bunch of stuff that appears to be the contents of the GAC. I assume that I shouldn't delete all of these values (?), but at the top of the list is the key:

    <no name> : REG_MULTI_SZ : ...

    This had a value in it, which I have now deleted in accordance with the advice here. Is that right? Or does "clear the default value" mean I should delete the key altogether (and not just the value there)? Sorry if this is a stupid question, but I'm new to fiddling with the registry...

    Secondly, deleting the files manually doesn't seem to be a good solution - for some reason I need to reboot before I can re-install the assembly (I'm currently developing an assembly so need to uninstall and then reinstall a newer version quite often), and then the same problem occurs again next time so I again have to manually delete, re-boot and re-install each time I want to test a new version of my assembly. Does uninstalling MSN Messenger fix the problem permanently?

    Thanks in advance for any advice you can give!
  • Anonymous
    March 28, 2004
    Kevin, the very first entry under that registry key is what you want to delete. If you're using regedit, it should have a name of "(Default)" and the value should have no value (regedit displays this as "(value not set)".

    Deleting files manually from the GAC is definitely not recommended.
  • Anonymous
    March 29, 2004
    Great - many thanks for your advice, Alan. Deleting the entire entry (not just the value) seems to have worked a treat.
  • Anonymous
    March 30, 2004
    DUDE i'm not worthy..thank you so much for solving my problem also...
  • Anonymous
    April 01, 2004
    Thx! "Global" key had a default value of REG_MULTI_SZ set to smth like "{Ja9`qF7V@7x@e9P@...". I just uninstalled MSN 6.1. Now its type is REG_SZ, it's empty and gacutil.exe works fine.
  • Anonymous
    April 02, 2004
    Alan!! You have no idea how much I owe you with this tip!!!! Thank youy very much!!!. People, you have to DELETE the key, not just clear the value, ok??
  • Anonymous
    May 10, 2004
    Alan, I know you heard many "Thanks" already. But this is the exact problem I have and your article solved it in 30 seconds. Thank you!!
  • Anonymous
    May 17, 2004
    One more to add to the "Thanks List" :)
  • Anonymous
    May 18, 2004
    Alan, you the man! thanks Mario - i cleared first then deleted thank to you.
  • Anonymous
    May 18, 2004
    Hi Alan, ... and MSN Messenger Development Team don't fix this problem yet at version 6.2. :S
  • Anonymous
    May 29, 2004
    i want my msn unstalled please!!!
  • Anonymous
    May 29, 2004
    i want my msn unstalled please!!!
  • Anonymous
    June 14, 2004
    You can go to c:winntassemblyGAC and remove your folder your_dll without_extension with rmdir folder name /s/q to get rid of the problem.
  • Anonymous
    June 15, 2004
    Thks!!!!!
    It really worked!!!!!!!
  • Anonymous
    June 18, 2004
    Addressing Hiren's comment, I'll repeat my recommendation again: simply deleting the directory by hand is not the right solution.

    For everyone interested, we've tracked down this problem to any MSI that installs native winsxs assemblies using the built-in MSI support. This ends up causing a corruption on pre-XP systems. There will be a fix in MSI3.0, and we're also looking at whether a MSI2.0 patch for this is feasible.
  • Anonymous
    July 05, 2004
    The comment has been removed
  • Anonymous
    July 06, 2004
    "Addressing Hiren's comment, I'll repeat my recommendation again: simply deleting the directory by hand is not the right solution."

    Why not? It seems to achieve the desired effect with the least amount of effort.
  • Anonymous
    July 06, 2004
    Do you uninstall programs by just deleting the files under program files? Sure, it might look like that works, but it almost certainly doesn't do what you really want.

    There is state that the system can maintain associated with the contents of the GAC. Going through an API ensures the necessary state is consistent with the contents of the store.

    The obvious example of problems today is traced reference counts being leaked. In future versions, the state of the store is used to determine coherency information with native images. Policy and other state will also be tracked in a similar way.

  • Anonymous
    July 06, 2004
    So deleting the directory is not "right"? What problems could this cause?
  • Anonymous
    July 26, 2004
    Thank you very much. This has been bothering me for a while and has been frustrating. I did what Alan suggested and it works!!!!!!!!!!
  • Anonymous
    August 05, 2004
    I do not see the path -

    HKCUSoftwareMicrosoftInstallerAssembliesGlobal

    on my NT 2000 machine.

    Where should i search for AssembliesGlobal ? to remove the Assembly reference.
  • Anonymous
    August 05, 2004
    You safe my night.
    Just delete the (default) key.
  • Anonymous
    November 27, 2007
    PingBack from http://feeds.maxblog.eu/item_676068.html
  • Anonymous
    January 21, 2009
    PingBack from http://www.keyongtech.com/555656-cannot-remove-an-assembly-from
  • Anonymous
    May 07, 2009
    PingBack from http://seiti.eti.br/blog/2007/compilation-error-cs0433
  • Anonymous
    May 29, 2009
    The comment has been removed