Recently in Visual Studio Category

visual_studio[1] Visual Studio 2010 Release Candidate is available for download (all three editions - Pro, Premium and Ultimate) and I ask you to install it, give a try and more importantly - try your real projects on it. Why bother? Because you can help to make it the best Visual Studio version ever. 10 might become new 6, but these small nasty beasties like this one can spoil everything. It is not too late to fix crashes and other severe bugs we might have missed. The bug bar is very high now, but crashes in common scenarios and data loss issues still can be fixed by RTM, we just need to know about them ASAP.

Here are some more download links:

1. Visual Studio 2010 SDK for RC

2. ReSharper 5.0 Beta 2 for VS2010 RC if you into it

3. CodeRush Beta for VS2010 RC if you can't live without it

Again: we desperately need your feedback. File bugs to or just post them here if you feel lazy.

Obviously Microsoft forgot about XInclude when they were shipping Visual Studio, so when you edit your XML and use XInclude you get no intellisense. It's easy to fix though. Just get this XInclude schema (standard XInclude schema improved a bit by Laurens Holst) and drop it into

{Visual Studio install drive}:\Program Files\Microsoft Visual Studio 9.0\Xml\Schemas

Now it's better:


IronXSLT v0.3 released

| 4 Comments | 2 TrackBacks | , ,

Here is a small quick release. IronXSLT v0.3.

New in this version:

A very little known fact is that Visual Studio 2008 does support real XSLT intellisense - not a static XSLT schema-based one, but real dynamic intellisense enabling autocompletion of template names, modes, parameter/variable names, attribute set names, namespace prefixes etc.

For some obscure reason it is off by default and obviously completely undocumented. I'll show you how to turn it on. But before - a little teaser.

1. When you about to call a named template you are presented with a list of all named templates in your stylesheet. My favorite feature. Finally you don't have to remember all your template names:

2. In XSLT template parameters are passed by name, so when you call a template and want to pass parameters you actually have to know exactly what parameter names are. And you better know them for sure, because if you make a mistake you pass a parameter with wrong name you get no error or even warning. XSLT 1.0 specification allows such nonsense.  That's why template parameter name autocompletion is a real time saver:

3.  You can pass parameters when applying templates too. Obviously due to dynamic XSLT processing model it's hard to know in advance which template will be matched at run time, so it's hard to suggest list of parameter names. In this version of XSLT intellisense we get list of all parameters used in all templates, filtered by mode. I believe XML Tools could optimize it a bit by filtering the list when it's clear from the context which template will be matched. Anyway, very useful:

4. Autocompletion of template modes is also extremely useful. Make mistake in mode name and you can spend hours in debugger trying to figure out why your template isn't matched, because again this is not an error or even something wrong according to XSLT spec. That's why this is so cool:

5. Finally a couple of useful namespace prefix autocompletions. exclude-result-prefixes now becomes easier:

and <xsl:namespace-alias> (mostly used for generating XSLT using XSLT):

6. If you use <xsl:attribute-set> elements, you will be happy to see this one:


These are autocompletions I'm currently aware of. There might be more - it's currently completely undocumented and I probably the first one writing about this feature. For example key names are collected too, but I haven't found where they are used. If you happen to discover another XSLT autocompletion, report it in comments section please.

And finally how to turn this awesomeness on:

Yes, regedit. Create String value called "XsltIntellisense" under "HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\XmlEditor" key. "True"/"False" are valid values.

If you are too lazy for editing registry manually, here is XsltIntellisense.reg file you can run (but rename it to .reg before).

If you don't want to mess with registry, wait till tomorrow. I'm going to release IronXSLT v0.3, which will turn XSLT intellisense on for you while installing.


Microsoft XSLT Profiler

| No Comments | 1 TrackBack | , ,

Microsoft XML Tools team has released XSLT profiler addin for Visual Studio 2008. I've heard about this tool and even did a little testing long time ago (apparently it's very hard to release anything in Microsoft).

First thing you need to know about Microsoft XSLT profiler - it requires Visual Studio 2008 Team System edition with the Performance Tools feature installed. That actually sounds a bit steep for just XSLT profiler, but it starts to make sense once you realize this tool is just a thin wrapper around the F1 profiler (which only ships with Visual Studio Team System SKU).

Once installed, it adds "Profile XSLT" command (visible only in XSLT context, i.e. when active document is XSLT stylesheet) to the XML menu:

Before you see profiling results you should recall that XSLT in .NET starting with 2.0 is compiled to MSIL:

As you can see, an XSLT stylesheet is being compiled into a class and each template becomes a method with cool special name like <xsl:template match="book">. That was smart. And yes, MSIL is completely ok with such kind of method names. Beside template-mehods the generated class contains other auxiliary stuff. So don't be surprised with XSLT profiling results:

I'd say there is too much clutter in this form. I'd like to see only XSLT relevant info, but as you can understand now, it's the the results of profiling compiled assembly and XSLT part is here only because smart compilation tricks.

Still extremely useful tool. A must for anybody writing XSLT in Visual Studio. Besides Summary View there are: Call Tree View, Modules View, Caller/Callee, Functions, Marks and Processes Views. You can find more info about profiling report details at

I'd be happy to see next version. With all clutter removed, more XSLT focused, linked to XSLT source (seems like currently there is no way to get back to template source from report), may be with some smart visualizations (what about coloring XSLT source view to indicate the hot spots?). Oh well, provided it took XML Tools team so long to ship this tool I better try to implement all these ideas myself in Iron XSLT (stay tuned, it's not dead as I'm back).

When you create new XSLT stylesheet in Visual Studio via project (Add/New Item) or globally (File/New/File aka Ctrl+N), you start with template content. This template is changing in every new Visual Studio version, probably because every new generation of developers working on XSLT tools in Visual Studio have different vision about what you should start with.

Let's see. Visual Studio 2003. Pure simplicity:

<?xml version="1.0" encoding="UTF-8" ?>
<stylesheet version="1.0" xmlns="">

Visual Studio 2005 has two different templates for new XSLT stylesheet (!). When you create it via project you get the same as above empty stylesheet template. But if you go via Ctrl+N you get this fancy template:

<?xml version="1.0" encoding="utf-8"?>

<xsl:stylesheet version="1.0"

<xsl:template match="/">
        This is an XSLT template file. Fill in this area with the
        XSL elements which will transform your XML to XHTML.


Yes, believe it or not, but some Microsoft developers were sure you should start with EXSLT namespace declaration in your stylesheet. The fact is that .NET 2.0 introduced partial native support for EXSLT, but it was never documented. It's still hidden portability gem.

Now what you get in Visual Studio 2008:

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl=""
    xmlns:msxsl="urn:schemas-microsoft-com:xslt" exclude-result-prefixes="msxsl"
    <xsl:output method="xml" indent="yes"/>

    <xsl:template match="@* | node()">
            <xsl:apply-templates select="@* | node()"/>

No more EXSLT, back to basics - proprietary nonportable MSXSL namespace by default. This is sad.

Beside this weird proprietary comeback it's interesting that this new template contains identity transformation rule. This cumbersome looking <xsl:template> is the base of data transformation filtering. It processes every single node in source document recursively and outputs it as is.  By adding more template rules you can override base behavior to add, remove or modify particular nodes. Very powerful technique. This is smart choice for new file template.

IronXSLT v0.2 released

| 4 Comments | 2 TrackBacks | , ,

Better later than never. I uploaded IronXSLT 0.2 release.

New in this version:

  • IronXSLT should now run without Visual Studio 2008 SDK
  • A notion of a Startup stylesheet in XSLT Library project
  • "Debug" page in XSLT Library project properties, which has Startup stylesheet dropdown list
  • "Set as StartUp Stylesheet" context menu item for XSLT stylesheets
  • "Start Debugging(F5)/Start Without Debugging(Ctrl+F5)" commands support - runs startup stylesheet

My goal was to make F5/Ctrl+F5 working intuitively right - when you work on XSLT Library project F5 should run project with debugger and Ctrl+F5 - without. When you have more that one stylesheet it's nice time saving feature, not to mention that start debugging command finally starts debugger as it should.

But what to run? So I introduced a notion of a startup XSLT stylesheet in a project. It's kinda like startup object in C# projects, but currently only affects debugging within Visual Studio. You mark your startup stylesheet either via project properties (Debug tab):

 or via new context menu item I added to XSLT stylesheets:

Once you have startup stylesheet in XSLT Library project you can start it as you usually start project with or without debugging:

I also spent unbelievable amount of time trying to make startup stylesheet bolded in Solution Explorer. It still doesn't work on project load...

Anyway, get IronXSLT 0.2 at It's free. Give it a try with Visual Studio 2008 Beta2. Find more documentation at

John Lam ported Textmate's Vibrant Ink theme to Visual Studio. Get it here.

Awesome. Note that toolbar buttons are nowhere to be seen. I noticed that while I'm only barely use toolbar, it still takes lots of space and more irritating - distracts attention like xmas tree and tends to rearrange itself I have no idea why. Besides turning toolbar off is the best way to learn keyboard shortcuts and once you do so you never look back.  While you at it, here is a nice Visual Studio .NET 2005 Keyboard Shortcuts poster from Jeff Atwood.

I'm a big fan of such kind of color themes. So far I was using Scott Hanselman's Visual Studio 2005 Font and Color Settings, but now I feel that's not eXtreme enough for me.

Btw, Windows Zune Theme is perfect match for Vibrant Ink theme. Try them out.

Update: check out also cool Moria color scheme port for Visual Studio by Tomas Restrepo (see comments).

Victor Garcia Aprea, the guy behind VSSDK Assist writes about his experience and vision of extending Visual Studio.

My Love / Hate relationship with Visual Studio:

Visual Studio is a tool I love to use.

Visual Studio is a tool I hate to extend.

Enough said. Ditto.

In another post, Dreaming of a huge Visual Studio Community, Victor says basically he's very pessimistic about Visual Studio community:

What is the hardcore way of extending Visual Studio: VSIP.

And what are the first things that come to mind when you think of “VSIP”: expensive and obscure. Expensive because it used to be 10k/year and obscure because its COM roots and it’s very poor (close to inexistent) documentation.

You tell me how do you build a huge community around expensive and obscure? You just simple can’t. I believe the past years were more than enough to prove this.

Can you build a community around VSX? Although this is surely an improvement over expensive and obscure, IMO, this is still not enough.


Because all of the “obscure” it’s still there. Because you still need to mess with COM interfaces all the time and the versioning craziness like “IVsComponentEnumeratorFactory3” and native structures and enumerations that were coded when naming like “__VSMEPROPID2. VSMEPROPID_LAST2” made any sense. Let alone the VBisms you can find in today’s DTE automation layer (like indexes starting at 1 instead of 0, etc). Also, I don’t want 45 different and incompatible ways of doing the same thing.

Well, again, I feel the same way. While VSIP is free now, I believe Microsoft already missed the chance to make Visual Studio the development platform of choice for masses. Think about it - when Eclipse didn't exist yet, Microsoft already had fully extensible rich Visual Studio platform, but they were stupid enough to make it fully closed, very complex and stunningly expensive. No wonder everybody loves extending Eclipse platform and even gurus hate extending Visual Studio.

Microsoft XML Team posted a series of screencasts unveiling some new features in Visual Studio Orcas 2008. Short ones, but to the point, without blablahblah. I particularly like XML Editor ability to generate stub XML document from XML schema in just one tab click. Oh, and XSLT debugging is getting better and better. Data breakpoints is a great feature.

Ok, done with sweet part. Black hat on. XSLT debugger still must be run using separate obscure button, called "Debug XSLT", which even has no keyboard shortcut. Hitting F5 will obviously start debugging C# or whatever actual project is. That sucks.

Every debugging menu item works for XSLT debugger, except well, "Start Debugger". I made this mistake zillion times - working on XSLT, want to debug, hit F5, getting C# debugger. Oh, wait, no I meant this button, where is it? That's wasted time. But come on, you are in C# project, that's why F5 starts C# debugger.

My solution to the problem is dedicated XSLT project type for Visual Studio I'm building in the IronXSLT. Separating is good here. The whole project is XSLT-centric, including of course F5 button. In XSLT project F5 will naturally start XSLT debugger.

Another painful point. Derek says his favorite XML Editor feature is "Go to definition":

One of my favorite 'hidden' features is goto-definition. Position the cursor on an element in a document with an associated schema, and F12 will jump you to the part of the schema that governs that element. I occasionally get some very complex customer schemas. F12 can also be used to navigate with-in a schema, from an element declaration to the declaration of it's type, or to the base type declaration. When the schema spans megabytes and multiple files, this is invaluable.

Call me a freak, but I hate "Go to definition" feature in Visual Studio XML Editor. Not because I think going to the definition is bad idea, but because it fools me too many times. It's useful feature when editing XML, but terrible joke when editing XSLT. And 80% of time spent in XML Editor I'm editing XSLT. Huge XSLT stylesheet, call to some template: <xsl:call-template name="go-find-me-template"/>. I want to see the template. Click on "go-find-me-template", F12 - Boom - XSD definition for xsl:template element. That sucks.

I mean it's not fully done. XSLT Editor must override "Go to definition" command and provide meaningful implementation. Currently it's wrong. Nobody wants to see XSD schema for XSLT. It's like when hitting F12 on a variable in C# code being shown C# grammar rule.

Again, I'm going to fix it in the IronXSLT. Not sure if I can override default "Go to definition" command, but at least I can provide my own, which will actually be useful in XSLT.

Craig Skibo of Microsoft writes about new thing they announced recently - Visual Studio Shell. What the hell is that? Marketing description is unreadable:

A streamlined Visual Studio development environment, the Visual Studio Shell provides the core foundation so you can focus on building your application’s unique features.

But Craig gives a description mortals like me can understand:

Over the years many people have been creating packages and Add-ins for Visual Studio, but if anybody wanted to use your package, they had to have a copy of Visual Studio (pro or above) installed on their computer or you had to license what we called the PPE (or “Premier Partner Edition” – another beautiful name) and it was not exactly cheap.

What I have been working on is allowing you to, by building a small exe program and editing an even smaller text file that looks like a .reg file, create your own application which consumes the Visual Studio shell. Your program is branded with your company name and logos in any way that you wish, the only place that any Microsoft logo appears is on the splash screen where on the bottom right we put the text “Powered By Visual Studio”. And best of all – it is free!!! You can also distribute the PPE version of Visual Studio Shell, for free!!!

Ok, so Visual Studio Shell looks like Microsoft answer to the Eclipse Platform.

That's a good move, but what bother me tough is the fact that building plugins for Visual Studio is still a nightmare compared to building Eclipse plugins. If Microsoft wants to achieve at least a portion of adoption Eclipse platform has they have to simplify Visual Studio SDK programming substantially. Which is hardly possible without substantial redesign/rewrite of this 10 years old monster.

Visual Studio Hawaii (next after Orcas) was supposed to be such new dramatically redesigned version. And this announcement sounds like a sign of a major Visual Studio redesign going on right now.

Yes, I'm trying to change the way you work with XSLT in Microsoft Visual Studio. It must be a pleasure to develop and rocket fast at runtime. Yes, Visual Studio already supports editing, running and even debugging XSLT, but it's still a painfully limited support. So I'm started building IronXSLT - Visual Studio plugin aimed to provide total integration of the XSLT language in Visual Studio IDE.

Current list of planned and already implemented IronXSLT features includes:

  1. XSLT Library Project (Visual Studio project type for compiling XSLT into DLL)
  2. XSLT Refactorings
  3. Multiple XSLT engines
  4. XSLT Profiler
  5. Extensive library of XSLT code snippets
  6. XPath Intellisense
  7. Visual XSLT builder
  8. XSLT2XLinq and XLinq2XSLT converters

IronXSLT version 0.1 implements first point.

IronXSLT supports only forthcoming Microsoft Visual Studio version, codenamed "Orcas", which is about to be released later this year. That also makes IronXSLT ship date.

IronXSLT is free for personal and commercial usage, but not open source currently.

To be continued...

Mark Miller announced Refactor! for ASP.NET v2.2 - free code refactoring tool from Developer Express. It includes 29 refactorings, including 10 ASP.NET related ones and is available for Visual Studio 2005 and Visual Studio Orcas Beta1.

ASP.NET refactorings include:

  1. Add Validator
  2. Extract ContentPlaceHolder
  3. Extract ContentPlaceHolder (and create master page)
  4. Extract Style (Class)
  5. Extract Style (id)
  6. Extract to UserControl
  7. Move Style Attributes to CSS
  8. Move to Code-behind
  9. Rename Style
  10. Surround with Update Panel

This is awesome tool and it saves me LOTS of time (I'm using Refactor! Pro).

My favorites so far:

Those lucky like me having Refactor! Pro - don't install Refactor! for ASP.NET, instead update your Refactor! Pro installation.

I installed Microsoft Visual Studio Codename Orcas Beta1 and was really pleased to see that it's finally capable of targeting not only .NET 3.5. It supports .NET versions 2.0, 3.0 and 3.5. This is going to be the first multitargeted Visual Studio version, so far I had to keep Visual Studio .NET for maintaining .NET 1.0 applications, Visual Studio .NET 2003 for .NET 1.1 applications and Visual Studio 2005 for .NET 2.0, what a mess (especially provided that single Eclipse installation works just fine with Java 1.3, Java 2, Java 5 and Java 6). Now that's cool.

For those interested here are some good info from MSBuild blog: "Multi-Targeting : How does it work?" and "MSBuild, Orcas, and Multi-targeting".

Hot, hot, hot! Microsoft Pre-release Software Visual Studio Code Name "Orcas" - March 2007 Community Technology Preview (CTP) is available for download.

This is the first mostly feature complete Visual Studio version (Visual Studio 2007 I bet).

6Gb download, so before click on the link take a look at what's new and decide if you need it. It's Pre-release and Community Technology Preview too. Anyway here are some highlights: