If you are developing add-ins for in-house use, chances are that you can drive, encourage or even force the whole organization to use the latest version of Visual Studio and therefore your add-in needs to target only that version. But if you are developing add-ins for commercial or open-source purposes, to be used by lots of people, your add-in needs to target several IDE versions (nowadays, at the very least VS 2005, 2008 and 2010). To simplify your life as a developer, you try to keep a single code base and a single binary dll. For example:

• You create the add-in with VS 2005 (and therefore .NET Framework 2.0 / CLR 2.0) with a single project, referencing EnvDTE and EnvDTE80, VSLangProj, VSLangProj2 and VSLangProj80, generate a single DLL, but you create the proper .AddIn file and put it in the proper folder to target VS 2008 too.

or:

• You create the add-in with VS 2008 (targeting .NET Framewor 2.0 / CLR 2.0) with a single project, with the same references than above, taking care of not referencing EnvDTE90 or VSLangProj90 (which are specific to VS 2008), generate a single DLL, but you create the proper .AddIn file and put in in the proper folder to target VS 2005 too.

Both approaches work. Some people use the first one to ensure 100% that the add-in will work with VS 2005 (since it was created with that IDE and .NET Framework 2.0) although I personally use the second one (I like VS 2008 much more than VS 2005) with no problems so far.

If for some reason the add-in needs to know the IDE version where is hosted or behave differently dynamically depending on the IDE version, it can guess it using DTE.Version or DTE.RegistryRoot, but there is no need to have separate DLLs if both VS 2005 and VS 2008 can use the same CLR 2.0, .NET Framework 2.0 and the same set of references.

Now, VS 2010 comes. So, your natural approach is to keep your existing code, binary dll and make it target VS 2010 adjusting the .AddIn file. Although VS 2010 uses a new CLR (4.0) instead of CLR 2.0, a CLR can load assemblies compiled against the previous version, in the same way that VS.NET 2003 (using CLR 1.1) could use add-ins created with VS.NET 2002 (using CLR 1.0) if the add-in was properly registered.

When you create your add-in with VS 2005 and you want to debug it on VS 2008, you just simply go to the Debug tab of the project properties and set the Start Action to start the devenv.exe of VS 2008, and this works perfectly.

Similarly, when you create your add-in with VS 2008 and you want to debug it on VS 2010, this worked perfectly until VS 2010 Beta 2. With the Beta 2 released two days ago you get the error:

The debugger’s protocol is incompatible with the debuggee

I have confirmed with Microsoft that this is not a bug, it is by design: VS 2008 (using CLR 2.0) or VS 2005 won’t be able to debug CLR 2.0 add-ins hosted in VS 2010 (which uses CLR 4.0). Which is a pity, but this means that your workarounds in the scenarios above are:

• Use VS 2010 to create a separate binary add-in DLL (CLR 4.0) for VS 2010 only. For me, this is the worst workaround, only considered as a last resort.
• Use VS 2005/2008 to create a single binary add-in DLL (CLR 2.0) to target VS 2005, 2008 and 2010, giving up debugging on VS 2010, resorting to MessageBoxes in your code to guess what’s going on if you need to debug a problem that can’t be reproduced when the add-in is hosted on VS 2005 or VS 2008.
• Use VS 2010 to create a single binary add-in DLL (targeting CLR 2.0 /  .NET Framework 2.0, not CLR 4.0 / .NET Framework 4.0) to target VS 2005 / 2008 / 2010. I haven’t test this yet but I hope it works. Even if VS 2010 can’t debug a CLR 2.0 add-in hosted on another VS 2010 instance, you can temporarily switch it to target CLR 4.0 and this should work. Once the problem is debugged and solved, you can switch it back to CLR 2.0. I hope that VS 2010 can also debug a CLR 2.0 add-in hosted on VS 2005 or VS 2008.

Let me know if you have more insights about all this.