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.