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