The strange case of 8013141A loading a Visual Studio add-in

A developer posted a couple of days ago in the MSDN forum about Visual Studio Extensibility that loading his add-in caused and exception with error number <Unknown Error> (8013141A). Of course, searching with Google doesn’t always offer much information about these bizarre errors, nor the tools of the Windows SDK for which this error is, well, unknown too.

Since the section of my article about troubleshooting crashes in add-ins didn’t help much, I have enhanced it with further and more detailed explanations, and a mention to this error:

HOWTO: Troubleshooting Visual Studio and Office add-ins

More on Visual Studio and .NET version numbering

Numbering is quite easy for any normal person (or even child) that you ask: 1, 2, 3, 4… For programmers it begins to get weird since many of them would say 0, 1, 2, 3… and when programmers need to version things, it goes absolutely crazy. It should be easy, though: a major number, a minor number (both quite visible to the end user) and some internal build number no so visible. So, you would have version 1.0. And the next major version would be 2.0. And some minor incremental version like 2.1. And something in between like 2.5. However early in the modern era of computing for the masses (that is, MS-DOS and Windows) we got something like Windows 3.11 for Workgroups (rather than 3.2) or Windows NT 3.51 (rather than Windows NT 3.6). And even in same cases letters like Windows NT 4.0 SP 6a. And we got four parts for versioning from Microsoft (major, minor, build, revision) and programmers from Oracle used even five parts. And then marketing people introduced a new scheme using years so you had Windows 95, Windows 98, and then something like Windows 98 SE, and then to something completely different without the year like Windows ME (Millenium Edition, don’t worry if you missed it) and then back to the year with Windows 2000 and then forward again without years like Windows XP or Vista and then back to square 1 (or 0?) with plain numbers again like Windows 7 (but not 7.0). OK, I am also guilty and I created MZ-Tools 4.0, then MZ-Tools 2005 and then back to MZ-Tools 6.0. I promise the next one will be 7.0 🙂

Now, to Visual Studio and .NET versioning. I wrote some time ago about some inconsistencies in the numbering used to version. I have created a more complete table. It would be nice that the table would be something like:

Visual Studio Commercial version 2002 2003 2005 2008 2010 (CTP)
Visual Studio ProgId VisualStudio.DTE.7.0 VisualStudio.DTE.7.1 VisualStudio.DTE.8.0 VisualStudio.DTE.9.0 VisualStudio.DTE.10.0
Visual Studio installation folder Microsoft Visual Studio 7.0 Microsoft Visual Studio 7.1 Microsoft Visual Studio 8.0 Microsoft Visual Studio 9.0 Microsoft Visual Studio 10.0
Visual Studio solution format 7.0 7.1 8.0 9.0 10.0
Visual Studio registry key 7.0 7.1 8.0 9.0 10.0
DTE version 7.0 7.1 8.0 9.0 10.0
.NET Framework folder v1.0 v1.1 v2.0 v3.0, v3.5 v4.0
SDK folder C:\Program Files\Microsoft Visual Studio 7.0\SDKv1.0 C:\Program Files\Microsoft Visual Studio 7.1\SDKv1.1 C:\Program Files\Microsoft Visual Studio 8.0\SDKv2.0 C:\Program Files\Microsoft Visual Studio 10.0\SDKv4.0
SDK registry key name (under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NET\Framework) sdkInstallRootv1.0 sdkInstallRootv1.1 sdkInstallRootv2.0 sdkInstallRootv4.0

But actually it is like this:

Visual Studio Commercial version 2002 2003 2005 2008 2010 (CTP)
Visual Studio ProgId VisualStudio.DTE.7 VisualStudio.DTE.7.1 VisualStudio.DTE.8.0 VisualStudio.DTE.9.0 VisualStudio.DTE.10.0
Visual Studio installation folder Microsoft Visual Studio .NET 2002 Microsoft Visual Studio .NET 2003 Microsoft Visual Studio 8 Microsoft Visual Studio 9.0 Microsoft Visual Studio 10.0
Visual Studio solution format 7.00 8.00 9.00 10.00 11.00
Visual Studio registry key 7.0 7.1 8.0 9.0 10.0
DTE version 7.00 7.10 8.0 9.0 10.0
.NET Framework folder v1.0.3705 v1.1.4322 v2.0.50727 v3.0, v3.5 v4.0.11001
SDK folder C:\Program Files\Microsoft Visual Studio .NET 2002\Framework\SDK C:\Program Files\Microsoft Visual Studio .NET 2003\SDKv1.1 C:\Program Files\Microsoft Visual Studio 8\SDKv2.0 C:\Windows\Microsoft.NET\Framework\v4.0.11001\sdk (*)
SDK registry key name (under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NET\Framework) sdkInstallRoot sdkInstallRootv1.1 sdkInstallRootv2.0 sdkInstallRootv4.0

(*) Notice that it uses the Microsoft .NET root folder and not the Visual Studio root folder.

It is left to the reader as an exercise to print this post, mark with a circle the differences between both tables and post a comment with your differences count 🙂

And why is this so important? For most users of Visual Studio, it really doesn’t matter. But for people developing extensions (add-ins, packages, etc.) for Visual Studio, it matters, because the extension needs to integrate within the Visual Studio host. It needs to place files in some folders (1). It needs to add/remove some entries to the registry (2). In needs to automate DTE for some tasks (3). It needs to get the paht to devenv.exe for others (4). It needs to get tools from the SDK to register (5). Its setup needs to use the Visual Studio ProgId registry key (6). Etc, etc.

(1) To register XML-based add-ins

(2) To register COM-based add-ins

(3) To remove add-in commands in VS.NET 2002/2003

(4) To remove add-in commands in VS 2005 and higher with devenv.exe /ResetAddIn

(5) To register COM-based add-ins with regasm.exe /codebase using a 3rd party installer such as InnoSetup.

(6) To detect if Visual Studio is installed or it is running.

And when your extension needs to target lots of Visual Studio versions for many years, you really need a table like the one above, because your brain won’t be able to recall all and if you did the proposed exercise you know by now that versioning patterns are unpredictable in Visual Studio and .NET (except for the “Visual Studio registry key” row, until now).

How to ask questions in a forum to increase your chances of an answer

Being developers I guess we all get the same feeling when some user of our application tell us that the app “doesn’t work”, or “it gives me an error” without further details. I am always tempted to reply “it works for me” to the first case and “which are the ‘first name’ and ‘last name’ of the error?” for the second case, to see if they get that more information is needed to do something about it. Yet after years in the forums I keep seeing lame posts written by developers that fail to give a meaningful subject, the version of the product that are using, the error that are experiencing, the code to reproduce it (or they provide the whole file of code with tons of lines), etc. I wonder how they expect to get a prompt and useful answer…

So today I decided to do something about it and I have written a sticky post in the MSDN forum about Visual Studio Extensibility:

How to ask questions to increase your chances of an answer

How many old Visual Studio versions does my add-in/package have to support?

I’m sure this is a question that every developer of extensions for Visual Studio, whether add-ins or packages, wonders from time to time. If you develop extensions for in-house use, you can drive, incentivate or even force your organization to migrate to the latest version of Visual Studio. But if you develop extensions commercially, things are quite different.

At the time of this writing we have the following Visual Studio versions:

  • Visual Studio .NET 2002, released in February 2002.
  • Visual Studio .NET 2003, released in April 2003.
  • Visual Studio 2005, released in October 2005.
  • Visual Studio 2008, released in November 2007.
  • Visual Studio 2010, to be released at the end of 2009 or in 2010.

Five releases start to be a lot of releases… even if you have managed to have a single code base for your extension (with some conditional compilation), or maybe even the same binary for several Visual Studio versions (with some dynamic adaptation to the Visual Studio version hosting the extension), and maybe the same setup, nothing can avoid you a lot of testing, to ensure that your extension works correctly on each Visual Studio version, because from time to time Microsoft introduces unintentionally new bugs. Furthermore, you would like to use new features of the .NET Framework like Generics of .NET 2.0, which you can’t use if your codebase is still to be build against .NET 1.0 or 1.1. You are also tired of having four whole releases of Visual Studio installed on your machine with identical shortcuts in the quick launch toolbar of your Windows (sort of Visual Studio 2008, which introduced the version number “9” in the icon). And some of the Visual Studio releases are not supported on your Windows Vista but since you want the latest OS, you don’t want to go back to Windows XP, so you install them anyway, and they work for the most part, but some very used features like Find hangs and you get frustrated…

So, you really wonder if you could drop support for VS.NET 2002. If your extension is a package, VS.NET 2002 didn’t provide support for 3rd party packages so there is no question. If your extension is an add-in, then you could probably drop support because VS.NET 2002 was the version 1.0 of the new IDE and it was somewhat incomplete and lacking some features that Microsoft took only one year to replace it instead of the usual two years cycle. And by the time people learned .NET and decided whether to use it for some serious project or not, VS.NET 2003 was out.

What about VS.NET 2003? This version introduced the Visual Studio Industry Program (VSIP) for packages, which in VS 2005 would evolve into the Visual Studio SDK. So, you really would like to get rid of VSIP and use only the new VS SDK, and dropping support for this version would mean that you can move your codebase to .NET 2.0, and your add-in can get rid of COM using toolwindows without a shim control, using XML-based registration rather than Registry-based registration, managed satellite DLLs instead of native C++ satellite DLLs, etc. And you wonder, how many people is still using VS.NET 2003? Hey, that’s stuff of five years ago! Could I get some usage statistics from somewhere, Microsoft perhaps? Do I send an e-mail to my customers? Do I drop support anyway?

Well, if you are a successful commercial vendor, you already know that all is about the customer, not about you, your technology, your preferences or your desires (if you are still a geek with disdain for marketing and sales there is good stuff to learn out there). So, let’s talk about the customer:

  • Customers hate when they have some software and hardware that at some point is not supported by the vendor, no matter how old. I remember that I had an HP CD recorder that when Microsoft shipped Windows XP was no longer supported. I found an article from Microsoft pointing to the HP web site, and indeed HP stated that they wouldn’t provide Windows XP drivers for that model. My CD recorder could be old and slow (4x, I think) but at that time it worked for my needs and if I needed to buy a new one to work with Windows XP, I may well purchase it from another vendor…. I haven’t purchased an HP product since then for that reason.
  • While you as a developer may have a MSDN subscription to get all the Microsoft software for development, many customers don’t. They buy some Visual Studio version and don’t upgrade unless they have the money and some compelling reason to do it (and maybe WPF, AJAX, etc, don’t qualify as a compelling reason). Think that the MSDN subscription is per-developer, not for a whole team. So only medium or big companies with special agreements (“Enterprise”, “Open”, “Select”) with Microsoft get new software as it is released. Students and hobbyists also get the latest versions in the form of Express editions, but these don’t support extensions, and you wouldn’t get much money from them anyway.
  • Even if a company has a software subscription with Microsoft and receives the new Visual Studio versions, they may have dozens or maybe more than a hundred .NET projects. And they have better (business) things to do than to migrate them just for technology purposes, forced by a vendor. Their company has already installed some .NET Framework version, and their projects and the Visual Studio version that they are using meet their needs. Or they use the latest Visual Studio version for new projects, but they don’t migrate the old ones because it takes time to do it.

So, despite your big desires of getting rid of old Visual Studio versions, as a developer of add-ons you need to support many previous versions of Visual Studio, and for many years. It’s the price you have to pay for developing extensions and not standalone applications. If I had doubts about dropping VS.NET 2003 support for my MZ-Tools add-in, the last two support e-mails that I have received about my MZ-Tools 6.0 for VS.NET add-in were from people still using VS.NET 2003… and you would be really surprised of how many people still download the version of my MZ-Tools 3.0 version of my add-in for Visual Basic 5.0 each month despite I would think that everybody had migrated to Visual Basic 6.0…

MZ-Tools Articles Series (update) HOWTO: Automating Visual Studio .NET from outside the IDE

I am these days trying to create a single .NET application that can automate all the Visual Studio versions installed on a machine (from Visual Studio .NET 2002 to Visual Studio 2010). For that purpose I have created a .NET application using Visual Studio .NET 2002 so it uses .NET Framework 1.0, which can run on any .NET Framework. Since I want to use early binding, I need to add a reference to EnvDTE.dll. And here I have found a problem; it happens that there are two versions of EnvDTE.Dll:

  • Version 7.0.3300.0: it is installed by Visual Studio .NET 2002 and 2003, but not by Visual Studio 2005 or higher.
  • Version it is installed by Visual Studio 2005 or higher, but not by Visual Studio .NET 2002 or 2003.

So, depending on the Visual Studio versions installed, you can have one version, the other, or both.

If the ,NET application references version, it won’t work when only Visual Studio .NET 2002 or 2003 are installed. If it references version 7.0.3300.0, it won’t work when only Visual Studio 2005 or higher is installed. Using a .config file to redirect version 7.0.3300.0 to won’t help, because if the system has only version 7.0.3300.0 installed, after the redirection it won’t find version

That means that you can’t automate all Visual Studio versions starting with Visual Studio .NET 2002 or 2003 using early binding. You have to use late binding, either using Option Strict Off (VB.NET) or Reflection (VB.NET / C#).

I have updated accordingly the article that I wrote back in 2005:

HOWTO: Automating Visual Studio .NET from outside the IDE

Fixed: Reading whole posts of this blog through a RSS reader

Today I have found the setting in the Community Server that hosts this blog that sets if the whole post or just a summary is published in the RSS feed. It was configured by default to publish only the summary so you got a “Read more…” at the end of an excerpt of each post when using a RSS reader. I tried to find the setting some months ago to no avail and today in a second try and after some searches on the web I have succeded 🙂

For other bloggers with the same problem, there are actually two settings, quite hidden (at least for me):

  • In the Control Panel, “Configure” tab, “Post Options” sub-tab, “Display” sub-sub-tab (no wonder I didn’t found it) there is a setting “Use post summaries in RSS” that by default was set to “Yes”. It needs to be changed to “No”. From this moment, the whole content of new posts is published, rather than a summary. Existing posts remain summarized, but you can change them with a second setting:
  • When you edit a post, go to the “Publication Settings” tab and there is a setting “Use post summaries in RSS”. By default it uses the general setting above but you can change it individually for each post. I have changed a few of past posts before getting tired…

So, you can now read whole posts with a RSS reader.

Modeless forms in add-ins

Basically you could use three kind of forms in your add-ins:

  • Modal forms: these are regular forms that are shown modally and block the UI until you dismiss them. For example, the Options window of Visual Studio.
  • Modeless forms: there are regular forms that are shown non-modally. For example, the Find dialog of the old VB6. AFAIK, VS.NET doesn’t use modeless forms at all.
  • Toolwindows: these are special windows that can be docked to edges of the IDE. For example, the Solution Explorer, etc.

It happens that modeless forms are tricky: they had some problems in VB6 (like not being minimized along with the IDE) and if I remember correctly they were unable to get the focus (or keyboard input, not sure) in Visual Studio .NET, so using toolwindows is almost mandatory in VS.NET. But my MZ-Tools add-in for VB6/VB5/VBA used modeless forms for some features, using a hack to be minimized with the IDE rather than staying on the screen. The hack involved some call to the SetParent Windows API and some change in the window style. It seemed to work OK, but this month I discovered by chance that when running on Windows Vista with Aero and transparency activated, the modeless windows appear without border at all! The problem seems to be the SetParent call but I have been unabled to fix it, so I have changed all modeless forms to toolwindows (the fix will be available next month). Curiously the only modeless form that I use in the version of MZ-Tools for VS.NET (a progress form for some operations) appears correctly with border using a similar hack. But the bottom line is that modeless forms should be avoided in add-ins: it is much better to use toolwindows.

.NET Frameworks, CLRs and Visual Studio add-ins

Each time that a new Visual Studio version appears on the horizon I guess that every add-in developer wonders about the question of how to make his add-in to support that new version: can I use the same current binary DLL that I have (with some tweaks)? Do I need a separate binary? The question of how to target several IDEs with the same binary (and setup) would be a great subject for a MZ-Tools Series Articles (maybe in the next months) but for now suffice to say that if your add-in is intended for VB.NET/C# a single binary can target VS.NET 2002/2003 and a different binary can target VS 2005/2008 (a single binary can’t target all because VS 2005 introduced a new DLL for commandbars). First, some clarifications about .NET Framework and Common Language Runtimes (CLRs):

  • A CLR is the base of a .NET Framework: it is composed by the loader/binder, JIT/NGEN, garbage collector, security model, profiling and debugging APIs, etc. and the Base Class Libraries.
  • A .NET Framework is a CLR plus additional libraries: Windows Forms, WPF, WF, WCF, etc.

We have two kinds of .NET Frameworks:

  • Side-by-side model: the .NET Framework is installed independently of other .NET Frameworks (it coexists with them). It uses its own CLR and it is complete. This is the case of .NET Framework 1.0 (VS.NET 2002), .NET Framework 1.1 (VS.NET 2003) and .NET Framework 2.0 (VS 2005).
  • Layer cake model: the .NET Framework is installed on top of other .NET Framework. It uses an existing CLR (not providing a new one) and it just supplies additional libraries. This is the case of the .NET Framework 3.0 (which introduced WPF, WF and WCF, but used CLR 2.0) and the .NET Framework 3.5 (VS 2008, it uses CLR 2.0 too). Notice that there is no CLR 3.0 or CLR 3.5.

Only VS 2008 can target several .NET Frameworks (2.0, 3.0 or 3.5). Previous VS versions can only target the .NET Framework they introduced.

An assembly compiled against a .NET Framework can run on ulterior .NET Frameworks (and CLRs) without problems (at least in theory, more on this later). For example, a .NET 1.0 assembly can run on a .NET 1.1 Framework. The opposite is not true for two reasons:

  • An assembly compiled against a given CLR can not run on a previous CLR. For example, an assembly compiled against CLR 2.0 can not run on CLR 1.0 or 1.1 (they know nothing about generics, for example).
  • An assembly compiled against a .NET Framework can not run on a previous .NET Framework, even if it shares the same CLR, because of missing libraries. For example, an assembly compiled against the .NET Framework 3.5 using WPF cannot run on the .NET Framework 2.0 despite both use the CLR 2.0 because a machine with only the .NET Framework 2.0 would lack the WPF libraries.

Ok, enough theory. Let’s start with some questions:

  • If I compile a standalone application (not an add-in) against CLR 1.1 and the machine has both CLR 1.1 and CLR 2.0, which CLR uses? Answer: by default it uses CLR 1.1, although it can be configured through a .config file to run on the lastest installed .NET Framework.
  • If I compile an add-in against CLR 1.0 and I register and run it under VS.NET 2003, which CLR uses, 1.0 or 1.1? Answer: it uses 1.1 (!), as you can verify putting a message box with the System.Environment.Version.ToString() in the OnConnection method. Add-ins, which run hosted inside some application, must all run with the same CLR (the lastest supported by the host). So, you can create an add-in with VS.NET 2002 (CLR 1.0) and run it on both VS.NET 2002 and VS.NET 2003. But you can’t create it in VS.NET 2003 (CLR 1.1) and run it on VS.NET 2002. Similarly, you can create an add-in with VS 2005 (CLR 2.0) and run it on VS 2008. And you could even create it on VS 2008 with .NET Framework 2.0 and use it on VS 2005 because both use CLR 2.0!

More questions about VS 2010, which is on the horizon (there is a CTP available):

  • Which .NET Framework does it use? Answer: it uses a new .NET Framework 4.0.
  • Does the .NET Framework 4.0 follow a side-by-side model or a layer cake model? Answer: it follows a side-by-side model.
  • Being a side-by-side .NET Framework, which CLR does it use? Answer: it introduces a new CLR 4.0.
  • Shouldn’t it be CLR 3.0 (after CLR 1.0, 1.1 and 2.0)? Answer: Microsoft tries to match the .NET Framework version and the CLR version, so CLR 3.0 is skipped.
  • Does it mean that .NET Framework 2.0/3.0/3.5 is no longer installed with VS 2010? Answer: it happens that VS 2008 introduced multi .NET Framework targetting, and VS 2010 follows suit targetting .NET Framework 2.0, 3.0, 3.5 and 4.0, so all of them are installed. Update (December 4, 2009): the installation of VS 2010 RTM will not include .NET Framework 2.0, 3.0 or 3.5, only .NET Framework 4.0. While VS 2010 can target those .NET Frameworks, you will have to download and install them.
  • So, can my binary add-in compiled against CRL 2.0 run on VS 2010 if registered properly?: Answer: yes (at least with the current CTP)

Now this gets tricky: the CLR 4.0 can coexist in the same Windows process with a previous CLR (2.0), something that was not possible before!. In the previous example, an add-in compiled against CRL 1.0 runs on CLR 1.1 (not on CLR 1.0) when loaded in VS.NET 2003. The same applies to other hosts such as Outlook, which uses the latest .NET Framework installed for all add-ins. But this can cause problems. For example, Microsoft discovered a nasty bug in a .NET 1.0 Outlook add-in used by their executives that when they installed .NET 1.1 caused a crash due to some new .NET 1.1 optimizations when starting threads. For that (and other reasons), a host can now use several CLRs (4.0 and 2.0) at the same time, loading each add-in in the CLR it was created for. This may or may not be a desirable thing, so you can configure it with a config file. (I am not sure which is the default behavior). This leads to the most interesting question:

  • So, my binary add-in compiled against CLR 2.0, does it run under CLR 4.0 or CLR 2.0 when loaded in VS 2010? Answer: well, in my tests with the current CTP, it runs under CLR 4.0 (the same behavior of previous VS versions). I am not sure if this is the default behavior, if it is something that will change later or what. I personally prefer this behavior (running under 4.0) because in my MZ-Tools add-in there are features that have to load assemblies from the .NET Framework to get property names of controls, etc. If the add-in runs under CLR 2.0 (because it was compiled against it), I doubt it could handle assemblies of CLR 4.0…

Very interesting (and tricky) stuff, isn’t it? You can learn more about the new CLR 4.0 in this PDC 2008 session:

Microsoft .NET Framework: CLR Futures

CommandBarPopups with an image (not possible) and split dropdowns (not possible either).

Today I received in the e-mail a question about how to create a commandbar popup with an image in a Visual Studio add-in. The short answer is that commandbar popups can’t have images but I will ellaborate it here a bit more.

First, we need to define what a commandbar popup is. A commandbar popup is a special button (on a toolbar) or menu entry (on a menu) that when clicked, rather than performing an action like a regular button, it shows new buttons or menu entries. For that reason commandbar popups show an arrow to the right of its caption (>). Examples of commandbar popups in Visual Studio are:

  • The File, New menu item
  • The Tools, Macros menu item.
  • Etc.

None of those commandbar popups have (or can have) an image. You can create commandbar popups as explained in my articles:

HOWTO: Adding buttons, commandbars and toolbars to Visual Studio .NET from an add-in.

HOWTO: Add a popup command bar to the context menu of a code window of Visual Studio .NET.

Now, there are other kind of “popups” and “dropdowns” in Visual Studio:

  • The “dropdown combo”. For example, the Configuration Manager combobox in the Standard toolbar, which allows you to select the active configuration (“Debug”, “Release”). Although not very useful for most add-ins, the good news is that you can actually create them with an add-in as Craig Skibo (formerly in the MS VS extensibility team) explained long time ago here: Command Bar Types – Part 2
  • The “split dropdown” (I am not 100% sure about whether this is the correct name, but I think it is). This is a special button that appears on toolbars (not on menus) and has two (splitted) zones: a button with an image that when clicked performs some action, and an arrow than when clicked drops down new buttons. An example of this control is the New Project button on the Standard toolbar. If you click the button, you create a new project. If you click the arrow, it shows buttons to create a project, web site, team project, etc. Notice that the image of the button and its associated action reflects the last used button, so this is also a kind of MRU control which wouldn’t be desirable in some scenarios for add-ins (that is, it is not actually like a commandbar popup). AFAIK, you can’t create this kind of control using an add-in although apparently there was some intention from Microsoft to support it (see my comment in the Craig’s post).

The strange case of empty Add-In Manager (not showing XML-based add-ins)

There is a problem that I have never experienced but it was happening for a few people in Visual Studio 2005 / 2008. The symptoms were:

  • The Add-In Manager is empty
  • The Add-In only shows registry-based add-ins, not XML-based add-ins (using an .AddIn file)

Of course the first difficulty was to notice that the problem happened to several add-ins, not only a specific add-in. When you don’t see your add-in in the Add-in Manager, the first thought is that your add-in is not correctly registered, specially because folders to put the .AddIn file are a bit tricky, as I explained in the article INFO: Default .AddIn file locations for Visual Studio add-ins (COM-registration is also tricky, BTW).

Using a file-monitoring tool like Process Monitor revealed that Visual Studio actually found .AddIn files, so there was no registration problem.

After almost one year with this problem unsolved, someone discovered yersterday the cause: a bad installation of MSXML 6.0, which apparently is used by Visual Studio to read the actual contents of the XML .AddIn files used by add-ins. After uninstalling MSXML 6.0 and installing the latest MSXML 6.0 SP1 the problem was solved. Here is the whole discussion thread with the problem:

VS 2008: Add-In Manager is empty

I have updated my article:

HOWTO: Troubleshooting Visual Studio and Office add-ins

I would be nice if Visual Studio showed an error message rather than failing silently when parsing .AddIn files, and better yet, used the XML parser of the .NET framework rather that depending on an external component.