This is another problem that was bugging me for quite some time: if an add-in uses a temporary user-interface rather than a permanent one when adding buttons to a built-in toolbar of Visual Studio, the add-in must remove the buttons when unloaded, typically keeping a reference to the CommandBarButton instance and calling the CommandBarButton.Delete method in the OnDisconnection method.
This approach has a problem that was affecting some customers of my MZ-Tools add-in: if Visual Studio or the add-in crashes, the add-in doesn’t have the chance of removing those buttons and they stay there forever, creating duplicates the next one that the add-in is loaded.
A better approach is to delete the command, rather than the button, when the add-in is unloaded (the command should be recreated rather than deleted to keep keyboard bindings). Deleting a command deletes all buttons, even “dead” ones. While this new approach doesn’t prevent duplicated buttons, they only stay there for a session. Using this new approach also solves the sporadic problem of COMException 0x800A01A8 that I already blogged about.
I have just written a new MZ-Tools Series article about this:
HOWTO: Prevent dead CommandBarButtons when Visual Studio or an add-in crashes
FWIW, MZ-Tools 184.108.40.206 (February 1, 2009) uses this new approach, which solves both problems.