This is something that happened me three days ago when I installed VS 2010 RC for the first time. I have tried to reproduce it several times to no avail, so I haven’t opened a Microsoft Connect report. FWIW, I will post here what happened just in case some of you want to test.

First, some background: when you develop an add-in for commercial or freeware use (not for in-house) chances are that you want to target multiple Visual Studio IDEs, ideally with the same binary DLL, just registering the add-in for several hosts. For example, an add-in built using CLR 2.0/.NET Framework 2.0 can target VS 2005, VS 2008 and VS 2010 (even if VS 2010 doesn’t install CLR 2.0/.NET 2.0 but CLR 4.0 / .NET 4.0). When the setup of the add-in is run, it can do two things:

• To install the add-in and register it only for the actual IDEs that are present on the machine. In this case, if the user later installs a new IDE version (supported by the add-in), he would be forced to run the setup again to get the add-in registration for that new IDE version.
• To install the add-in and register it for all the IDEs supported, even if they are not installed.
  • For COM registration this dirties a bit the registry creating keys like HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\10.0\Addins\<addin> that should not be there if VS 2010 (10.0) is not installed yet, so I don’t like this very much.
  • For XML registration, it happens that you can have a single .AddIn file in a location whose content specifies multiple hosts, so you don’t dirty anything targeting IDEs that are not installed yet. When the user installs a new IDE, the next time that he launches it the add-in will be there. No need to re-run the add-in setup. This is cool and this is the scenario where the problem happened with VS 2010 RC, but only once.

I had a new version of my MZ-Tools add-in that uses XML registration and targets VS 2005, 2008 and 2010 using a single XML .AddIn file, and it is marked to load on startup, and then I installed VS 2010 RC for the first time in that particular machine. The installation went OK, and when I launched VS 2010 RC for the first time, VS showed the usual message asking for a profile and indicating that it was initializing for first use, which could take a few minutes. The add-in was loaded two (I know because it shows a welcome kind of message).

When VS 2010 RC was done, I noticed that most of the user interface of my add-in was duplicated: two main menus (one of it disabled), two toolbars, etc. I went to the Add-in Manager and unloaded it, which caused a crash in VS and finally I was able to delete by hand the toolbars, menus, etc. Once cleaned, next times the add-in loaded well as expected.

I don’t know for sure what happened there, but it seems as if VS 2010, as part of its initialization, tried to persist the menus, toolbars and buttons of my add-in (that uses temporary UI) on disk as it does with packages and add-ins that use permanent UI. So the IDE ended with duplicated UI.

To reproduce the problem, I thought that the same thing would happen if I created another user account and launch VS 2010 for that user, since VS will need to ask profile, initialize user settings, etc. But I was unable to reproduce the issue.

Then I went the long route of installing VS 2010 RC on virtual machines with the add-in already registered, and I was unable to reproduce it too.

So, I don’t know if it is a timing issue (when the add-in is loaded and when VS persists UI on disk) or what… but I know what I saw and there is a bug somewhere there…as I explained in other posts, VS doesn’t take much into account that buttons can belong to add-ins that use a temporary UI, not always to packages or add-ins using permanent UI.

To play safe maybe I will change the setup to not register the add-in for IDEs not installed yet, but I am almost sure that the problem should happen too if the VS is launched by a new user on the same machine

I hope this helps. Let me know if you encounter this issue to reproduce it and send it to Microsoft.