I spent quite a few hours yesterday dealing with an intriguing thing that hapenned two days ago while I installed Windows Vista in Spanish on a new computer. To my surprise, every setup that I tried suggested “C:\Program Files” (in English) as the default destination, instead of “C:\Archivos de programa” which is the localized Spanish name. I changed a few things, delete some folders and in the end I had to reformat the hard disk. So, after reformatting I verified that setups insisted on suggesting “C:\Program Files” as destination folder instead of the Spanish localization. How come? I investigated and here are my conclusions:

• Previous to Windows Vista, there were English versions of Windows and localized versions of Windows. For the localized versions the folder names are localized. Windows XP also allowed Multiple User Interface (MUI) where you install a language pack over an English version and you have the user interface localized. This is similar, but not the same (regarding folder names), than a localized Windows version.
• Windows Vista eliminates localized versions and instead uses MUI for all languages (even English). There is a language-neutral base and language packs. A consequence of this is that folder names are no longer localized. So, the folder for programs is always C:\Program Files, even is the language pack is Spanish.
• Until Windows XP, when you call the Shell API functions SHGetSpecialFolderPath, SHGetFolderPath or the System.Environment.GetFolderPath of the .NET Framework it returns the localized folder name. On Windows Vista, it returns the English name (the one actually on disk). For this reason older setups now suggest C:\Program Files always, instead of a localized name. This will confuse the user, of course.
• To complicate things, despite that the actual names of the folders on disk are always on English, the shell of Windows shows them in a localized way. For example, using the Windows explorer the folder “C:\Program Files” is displayed as “C:\Archivos de programa” and “C:\Users” is displayed as “C:\Usuarios”.
• To complicate things even further, there are two hidden “junction points” in the root folder of C:. A junction point is just a link to a folder. One of junctions points is from “C:\Documents and Settings” to “C:\Users” and I guess this is because that location has changed, and there could be legacy setups that used the hardcoded the path “C:\Documents and Settings” instead of calling the Shell API. The other junction point is from “C:\Archivos de programa” to “C:\Program Files” and it is more intriguing because no setup would hardcode a non English folder name. So, which is the purpose of this joint point? I suppose that it only makes sense if you are upgrading from Windows XP to Windows Vista (rather than a clean installation).
• There is a new shell API function in Windows Vista, SHGetLocalizedName, that returns the localized name of a folder, as the Windows Explorer shows it to the user. I hope that new installers and setups become aware of Windows Vista an use this API function to suggest a destination folder like “C:\Archivos de programa” instead of “C:\Program Files” in the textbox for the location of the application. Once the installer gets a localized destination folder, the junction point from “C:\Archivos de programa” to “C:\Program Files” should make it install in the correct location.

Why all these changes? Apart from the new unified MUI approach that dictates non-localized names on disk (only localized when displayed to the user) and that there is a stupid 260 character limit in paths that MS would like to fix and that makes long folders names like “C:\Documents and Settings” not very friendly, it seems that MS preferred safety on folder locations even it that means confusing the user and for that reason they changed the behavior of the Shell functions. So, the implementation model wins over the user mental model. Now we can only hope that new setups aware of this Vista problem fill the gap to show to the user only localized names like the Windows Explorer does, not actual names on disk.

There are some intriguing things about macros. One of them is how to add a custom assembly to the Add References dialog of the Project Explorer of the Macros editor. I have documented it in this article:

HOWTO: Add a custom assembly to the Add References dialog of Visual Studio macros editor
http://www.mztools.com/Articles/2007/MZ007.htm

Other one that I had noticed is that apparently breakpoints on environment event handlers (such as BuildEvents) are ignored. I have discovered that Craig Skibo documented how to debug event handlers it in the Wiki part (Community Content) of the MSDN documentation (http://msdn2.microsoft.com/en-us/library/h9b001cb(VS.80).aspx):

“To debug an event handler, set a breakpoint on the line of code within the event handler where you want execution of the event handler to break. Then, place the editor caret ourside the body of a function, subroutine or event handler, and press F5 to set the Macros editor into debug mode. Perform a task which would cause the event handler to be fired.”

Visual Studio “Orcas” will feature a new Web Form designer codenamed “Quartz” based on FrontPage technologies replacing the one of Visual Studio 2005 codenamed “Trident” based on IE (MSHTML):

Sapphire: New Web Form designer in Visual Studio Orcas
http://blogs.msdn.com/mikhailarkhipov/archive/2007/01/20/sapphire-new-web-form-designer-in-visual-studio-orcas.aspx

If you have tried to make your Visual Studio add-in to work with WebForms or HTML pages, you know how difficult it is. So, I have opened a suggestion in the Microsoft Connect website for feedback:

Add extensibility support for WebForms/HTML forms in VS Orcas
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=254426

You can visit it and add your vote to my suggestion. Hopefully we can have a better extensibility for Webforms/HTML pages in VS Orcas. The February CTP will be the starting point to test it.

In a previous post I mentioned several tools that are part of my toolset as an add-in developer. In this post I would like to mention Microangelo, an icon editor that I use to create the icons/pictures for the command buttons of my MZ-Tools add-in. Once created there, I copy and paste them in the image editor of Visual Studio to change the background to almost green (R=0, G=254, B=0) that you must use for command pictures as explained here:

HOWTO: Creating custom pictures for Visual Studio .NET add-ins commands, buttons and toolwindows.
http://www.mztools.com/articles/2005/MZ007.htm

I have been using MicroAngelo since almost 10 years ago, when I started working at my current company where we purchased it. I liked it, so years later I purchased a license of version 5.x for my own use on Windows XP and I used it to create the TrueColor icons of the version of my add-in for VS 2005, which was very easy thanks to the tool (I am not very talented for graphics but I got managed to create some gradients). But several weeks ago I got a new laptop (a very nice Sony Vaio SZ3) and I installed Windows Vista, Office 2007, but alas, the capture feature of Microangelo 5.x did not work. Today I have got a new version 6.0 of Microangelo that is compatible and certified for Windows Vista 🙂

It has been several weeks since my last post but December 2006 was a quite hectic month, apart from the Cristhmas I got a LASIK operation for myopia on December 1 and I worked hard to get a new build of my MZ-Tools add-in with many optimizations for January 1. So, Happy New Year!

I also got the MVP title one more year on January 2 so the year could not start better…that means my 4th year as MVP, still in the generic “Visual Basic” category since there is no enough people for a “VS extensibility” category. But it doesn’t matter, I am commited to VS extensibility and this year I do plan to write many more mini articles (HOWTO, BUG, etc.) on my web site that I will announce here.

Microsoft has just published some early specifications (http://msdn2.microsoft.com/en-us/vstudio/aa948851.aspx) about the new Visual Studio “Orcas” and among them, it is the “CommandBar Improvements” (http://download.microsoft.com/download/5/9/c/59cd0dc5-4691-4c3e-840c-66d865f27692/command-bar-improvements.xps) which has an intriguing paragraph:

“The work we will do here will cause us to diverge from Office’s MSO Commmand Bar look and feel. Office 2007 (formerly known as Office “12”), will still use MSO Command Bars in applications such as Outlook. There, for example, customers will still see bubbly, beveled Command Bars. We believe that it is appropriate for Visual Studio to diverge from Office’s Command Bar appearance”

So, it seems that for the first time Visual Studio “Orcas” will not borrow the commandbars from Office, and I don’t know how to feel about that because all add-in developers know that creating commandbars and buttons in Visual Studio is tricky and to give a button a transparent custom picture is, well, I don’t want to get started about this… Also, I have experienced (well, my customers too) random COMExceptions (although very very rarely) creating or destroying commandbars, which are not reproducible and therefore don’t seem to be a problem on the side of the add-in. So, with a new commandbar model it could be that things get worse, or that finally commandbars are easy and problem-free, time will tell, but what is sure is that if those especifications get real, add-in developers will have to test their add-ins since the early CTPs of Orcas with the new commandbars, to report the problems that they find with the new model. Stay tuned!

Microsoft has a FAQ: Visual Studio and Windows Vista (http://msdn2.microsoft.com/en-us/vstudio/aa948854.aspx) where it is stated that Visual Studio .NET 2002/2003 will not be supported on Windows Vista, and that only VS 2005 will be supported with the SP1 and a (post-SP1) Vista Support Update. I have some comments about this:

The first one is that although .NET Framework 1.x applications will be supported, since an add-in is intended to be hosted inside a Visual Studio IDE, and since VS.NET 2002/2003 will not be supported, there is no need to test an add-in for those IDEs on Windows Vista.

Second, the VS 2005 SP1 will ship soon (maybe December 2006, maybe January 2007) and the Vista Support Update will be released “in the first quarter of 2007” but SP1 will not wait until then because “Delivering great product quality is something that we have always aimed for. We wanted to deliver the update to Visual Studio 2005 as soon as possible to our existing customers”. Given the long delay of the SP1 of previous IDES (VS.NET 2002/2003), it is quite shocking that VS 2005 SP1 can not wait a couple of months and include the Vista Support, because to run VS 2005 on Vista you will have to go through three installations, and it can be a mess.

My MZ-Tools 2005 add-in, like many others migrated from VS.NET 2002/2003 still uses COM registration, rather than XML registration (.AddIn file) and since it wants to be a good citizen in the new Windows Vista operating system, it uses HKEY_LOCAL_MACHINE to register within Visual Studio 2005 so the administrator installing it makes it available to other users of the machine (which may be other than the administrator). Previously I was using HKEY_CURRENT_USER but since I changed to HKEY_LOCAL_MACHINE, I am experiencing a problem that many of you will have seen: the Add-in Manager of VS 2005 does not persist changes in the Startup column if the add-in uses COM registration, even if you are an administrator of the machine.

I investigated this issue in the Microsoft Connect database and to my consternation it was reported twice but either the bug reports were not very clear or the Microsoft team failed to understand the problem so it is still unsolved, I reported it a third time, very clearly (I hope) but MS has answered that there is no time to fix it for SP1. So, if your add-in is affected by this problem take a look and vote for the bug to get it fixed for SP2 or VS “Orcas”:

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=238492

I have been visiting forums about Visual Studio extensibility since year 2002 or so, and it is almost a law that if you are a newbie starting in this world of add-ins, you will have to ask the same questions that others before you because you don’t know the basics or you find an unexpected behavior. So, I have written many HOWTO, INFO, BUG and PRB articles on my web site but here are the most popular.

If you only have time to read one of the articles, this is the most popular one:

HOWTO: Adding buttons, commandbars and toolbars to Visual Studio .NET from an add-in
http://www.mztools.com/articles/2005/MZ003.htm

Chances are that if you are writting an add-in, you will need a command and a button and likely a set of them so you will want a toolbar. Alas, commands, buttons and commandbars are the most difficult part of writing add-ins, so ensure that you understand how they work. The question is so complex that there are several related articles at the end of that one, so I won’t repeat them here.

If you are working with C#, then ensure that you read this one:

PRB: Visual Studio .NET events being disconnected from add-in.
http://www.mztools.com/articles/2005/MZ012.htm

Because again, chances are that you will want to capture events, and if you don’t do it correctly, you will capture them for a while but at some point you won’t capture them. VB.NET developers are more fortunate and thanks to the WithEvents keyword they don’t incurre in the pitfall described in the article.

Before I said that creating commands, buttons, and toolbars is the most difficult task and now I realize that I lied. Or at least, partially. The most difficult task is to put a custom picture in a button, and once you think that you have got it, you are only half way, because, of course, you want it transparent and sometimes you get it green, or magenta, or gray. Somehow, Microsoft have managed to do this incredibly painful since VB5 back in 1997 and it is yet painful in 2005 with VS 2005 and I wish it was so easy as to pass a .NET managed icon (icon, which support transparency, not bitmap) but I have no hope for VS “Orcas” in 2007 ten years later so get familiar with the lime green and magenta colors, a resource editor, a satellite dll and here we go:

HOWTO: Creating custom pictures for Visual Studio .NET add-ins commands, buttons and toolwindows
http://www.mztools.com/articles/2005/MZ007.htm

If you want to work with Windows Forms controls from an add-in, you need to meet a new (foreign) guy in town, the PropertyDescriptor type:

HOWTO: Manipulating controls of Windows forms from Visual Studio .NET add-ins.
http://www.mztools.com/articles/2005/MZ001.htm

If you are just creating macros (not even add-ins) to navigate your code (projects or code elements), again a tricky proposition, here are the ones that you need:

HOWTO: Navigate the files of a solution from a Visual Studio .NET macro or add-in.
http://www.mztools.com/articles/2006/MZ004.htm

HOWTO: Navigate the code elements of a file from a Visual Studio .NET macro or add-in
http://www.mztools.com/articles/2006/MZ008.htm

Sometimes you want to work with the references of a project but, alas, they don’t appear in the EnvDTE namespace. Did Microsoft omit them? No, but they are a little hidden:

HOWTO: Getting information specific to VB.NET and C# projects from an add-in or macro.
http://www.mztools.com/articles/2005/MZ011.htm

And finally this one also appears from time to time: how do I create a tabbed window (like a document window) from an add-in? Well, a toolwindow will do the trick:

HOWTO: Understanding toolwindow states in Visual Studio
http://www.mztools.com/Articles/2006/MZ025.htm

And of course, you have lots more here:
http://www.mztools.com/resources_vsnet_addins.htm

I’ve been always fascinated about drivers, plugins, etc. They allow you either to extend a system with new functionality or to use a system with pieces of hardware or software from different providers:

• Back in the early 90’s when I was in college I wrote a program to make crosswords that I sent to a company which published them. I pressed a button once a month to make dozens of crosswords, the program sent them to my dot-matrix printer, I carried them to the publishing company and I got the money in my bank account some weeks later. When I graduated and I started to work in a real company I had to work 40 hours per week for the same money at the end of the month so life has not been so great in that regard since then ;-). The first versions of that MS-DOS program were monolithic, with all the code to generate different crosswords and to print to different printers inside the code. In MS-DOS you didn’t have the luxury of Windows drivers for printers, you had to send escape codes to the printer, which were different for IBM, Epson or HP emulations. Later I moved that code into driver files for crosswords and printers so the actual code of the program was reduced to the half.
• Later in the college for graduating I had to make a MS-DOS program for digital imaging and again I spent a lot of time writing a mouse driver which worked with different graphic cards in resolutions higher than VGA (640×480), when Windows and its card drivers did not exist yet.
• Later, then in the corporate world, I learnt about databases and the ODBC drivers. In fact, I gained a lot of experience working with the ODBC API.
• Then I learnt about source code control (SCC) systems and the MSSCCI plugins which allows an IDE to work with different SCC providers.
• Then I learnt about Visual Basic and Visual Studio add-ins and when I made the .NET version of my own MZ-Tools add-in I made it extensible through an MZ-Tools SDK and DLL plugins.
• Visual Studio .NET allows you to use projects and code in different languages (VB.NET, C#, C++, etc.) and provides a unified extensibility model for all them so theoretically your add-in does not have to worry about the target language.

And so on… In a broad sense, you can also think about a kind of reverse plug-in: you have a piece of code and it works on different platforms. For example, a Java J2ME game to be played in different phones (I did a crossword J2ME game a couple of years ago) or an HTML page to be viewed in different browsers. In this case, the operating system or the browser are like plug-ins for your piece of code.

So, all this stuff of drivers, plugins and the such are great and make our life easier, don’t they? Well, not exactly:

• If you have tried to make your program work with, say, Oracle and SQL Server you know that you cannot be database-agnostic. Despite all efforts put in ODBC, OLE DB, ADO, ADO.NET, etc. you have to know which database vendor you are using to deal with different server behavior, database driver or SQL syntax (despite ANSI SQL or ODBC syntax). And if you have tried to test your app with different ODBC drivers for the same database, for example the drivers for Oracle made by Oracle and the ones made by Microsoft, you know that they behave differently. The only solution for these two scenarios is to write your own abstraction database layer on top of the database driver to deal with the peculiarities of each database or driver.
• Your experience printing to an HP Laserjet printer can be quite different in performance or output if you are using drivers from Microsoft or from HP. Technicians know what is a driver, what is a manufacturer, how to replace a driver, etc. but the end user doesn’t.
• According to Eric Sink from SourceGear, which makes Vault (a replacement for SourceSafe), the planet will certainly be a nicer place to live when MSSCCI is a distant memory. In fact the new extensibility model for source code control providers in VS 2005 to overcome the problems of MSSCCI is to make your own provider from scratch, which is what Team Foundation Server does and what SourceGear plans to do
• If you are going to use the extensibility model of Visual Studio .NET for a serious add-in, you are better off creating your own abstraction layer on top of it, with your own classes like SolutionEx, ProjectEx, ProjectItemEx, CodeElementEx, and so on because things are not the same with a VB.NET project or a C# project, not to mention a C++ project. You will find exceptions when calling methods in some languages, but not in others, or bugs in how a language implements its extensibility, etc.
• The new Document Outline feature of Visual Studio 2005 theoretically should work with all kind of visual designers, since all components implement the IComponent interface and .NET 2.0 introduced the new ITreeDesigner interface to know the children of a control (better than Control.Controls). But it you look closely, you will notice that the document outline treeview is not the same for Windows forms and for HTML/Web forms. And even further, the document outline treeview for the new Visual Studio 2005 extensions for Windows Workflow Foundation (WWF) is also provided separately by the WWF packages. My MZ-Tools add-in provides a Control Explorer feature that mimics the Document Outline feature, but adds value with more options and a handy “most used properties” feature, so I spent a lot of time studying the Document Outline feature and trying to catch up with the new visual designers of VS 2005.
• If you try to run a J2ME midlet in those actual phones of Nokia, SonyEricsson, Siemens (BenQ) or Motorola you will notice it does not work exactly the same (you can’t even rely on the software emulator of a phone) and you have to identify the phone brand and sometimes the model to deal with specific behaviors.
• And what to say about different Internet browsers or different versions from the same manufacturer? …

So, drivers and plugins and extensibility are not the panacea, it’s quite tough, not for the faint of heart, but it is the price to pay for open (and cheap) systems and it is still an exciting world for a developer 🙂