Editing XAML files in Visual Studio 2012


Finally, after three attempts, Microsoft have gotten a decent XAML editor into Visual Studio. Well done!

I’ve been doing some Windows Phone development recently, and using VS2012 professional for it. I also have Blend installed – I’ve blogged in the past about the positive impact it can have on a developer’s productivity. That still applies today, but the built-in designer / editor in VS2012 is much, much closer to Blend.

For a start, it actually performs quite well, with a markup editor that is reasonably responsive, so you don’t have to resort to editing in plain XML. You also get the ability to modify templates directly in the designer rather than having to go to Blend or do them by hand, and you also get decent property editing like colours, brushes and styles directly in VS – very similar to the Blend property pages, actually.

In fact, I like it so much that for a few days now I’ve done without Blend and been happily doing MVVM-style development without really missing it that much. Not that I’ve been doing anything fancy at all – just some views with bindings, templates and styles really – but that’s what most of us probably do anyway most of the time.

So, if you’ve been put off XAML in the past because of the VS experience, give it another go – it’s definitely workable now.

Expression Blend – a powerful tool for developers


I’ve been experimenting with the use of Expression Blend as a tool in the life-cycle for day-to-day development for a typical .NET developer that might be writing an application using Silverlight with some sort of implementation of MVVM.

Having used Visual Studio 2010 as my primary, all-in-one tool for developing applications, I was somewhat sceptical of using Blend. When I had tried the earlier versions of Blend, I didn’t like the look of some XAML it generated. Moreover, I simply couldn’t see the point of it – why run two applications to do something when one can do it. I’m no UX designer – I’m a .NET developer! So why should I use some code-gen tool to write badly-formed XAML when I can hand-craft it and do a much better job of it?

However, I recently became more and more frustrated with the performance and reliability (or lackof) within VS2010 when it comes to authoring XAML-based UIs, and so a couple of weeks ago I decided to try Blend again, and I think that this time I’ve “got it”. I’ve been using Blend along with Visual Studio 2010 to develop a relatively small Silverlight application, and have found it to be a powerful and useful tool in the arsenal of an application developer.

Why Blend?

Whilst the VS2010 XAML editor isn’t that bad, there are a number of benefits that I’ve found in using Blend to VS2010: –

  • Because the Blend designer is much more powerful than VS2010, I can see how styles and data templates will look without having to run the application. You’d be amazed how much time this saves.
  • The Blend editor is much, MUCH quicker and more responsive than VS2010. It got so bad with me in VS2010 that I ended up writing all my views in XAML-only mode at one stage. With Blend, 90% of what I do is in the UI mode; occasionally I’ll switch to XAML or split view to fine tune something, but the tool is generally fine for every day UI design.
  • Animations and Visual States are much easier to design in Blend.
  • The XAML editor is much quicker in Blend, because it doesn’t have as powerful XAML intellisense as VS2010. This is actually not usually much of a problem because, as I said, you end up using the designer most of the time.
  • Much, much easier to design data templates (or create new ones based on an existing one)
  • Encourages you to write clear separation between your View and ViewModels – design the former in Blend, the latter in VS.
  • Easier to use behaviours – Blend has a built in repository of them so you can just drag them on. No faffing around with manually entering the namespace in your XAML etc.
  • Data Binding is quicker and easier to achieve – including use of converters etc..
  •  

    I’ll stop there, suffice it to say that for most day-to-day tasks, it’s a much more pleasurable experience (or less painful perhaps?) in Blend. There are a few things that I’m still struggling with, such as how to effectively generate fake data to test out my views, and also how to get better control of how your view model is created – I like using Unity to create my View Models (typically as a dependency setter on the View’s code-behind) but if you create your View Model in Blend as a static resource, you can’t really do this.

    Typical Workflow

    I have to say that I’ve been really pleased with using Blend, so much so that it’s now become my default environment for XAML authoring. The best part of it is how seamlessly it integrates with standard VS2010 workflow, which now goes something like this: –

  • Load the solution in VS 2010 on one monitor
  • Load the same solution in Blend on another monitor
  • Code my data models, services, and view models in VS 2010 with CodeRush etc. etc..
  • Build the project in VS
  • Switch to Blend. It automatically picks up any changes to the View Model.
  • Author the View in Blend
  • Save the View xaml file (not build – just save it)
  • Compile the solution in VS2010 (which picks up the amended .xaml file automatically)
  • Run
    It doesn’t sound much but I’ve found it to actually be a really compelling way to work.

    Conclusion

    I still use VS2010 – it’s still a powerful development environment where I can quickly knock up code-based elements of my solution (especially with good old CodeRush) – but for designing views, Blend now has my full support. We’re often no longer writing simple WinForms that perform simple data binding with a couple of buttons and a listview. We’re now writing applications that have custom chromes, complex data binding with converters, asynchronous service calls with busy indicators, data templating etc. etc. – perhaps this is as good a time as any to treat VS as a code-first tool, and leave the UI design to Blend.