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:

But actually it is like this:

(*) 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).

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
http://social.msdn.microsoft.com/Forums/en-US/vsx/thread/9307ca0b-d152-4c31-85f5-05b6166d7410

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…

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.

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.

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).