WPF Training, anyone?

The team over at Framework Training approached me recently about putting together a training course for WPF and possibly UI Automation. I’ve been giving it some thought, but I need your help.

What would you like to see in a WPF course? Or perhaps, more to the point, what do you think your non-blog-reading colleagues would benefit from hearing about? Are there any areas you can think of that are not covered by existing courses?

I’m guessing that the world doesn’t need another WPF 101. But people might like some help on more advanced topics, such as using the MVVM pattern, extending the declarative powers of WPF with Triggers and Behaviors, or even learning how to write robust tests against their UI using the UIAutomation API.

So, over to you. The comment box is open … now!

And if you think the world doesn’t need another WPF training course, tell me what you would like to see. And feel free to give me the benefit of your wisdom on how training course in general should or should not be run.

Perhaps an incentive would help you put fingers to keyboard? I’ll give a £25 Amazon voucher to the person who (in my judgement) leaves the most helpful suggestions.

Update: My thanks (and, more concretely, a £25 gift voucher!) go to Jedrzej Sztompka who emailed in a copious list of suggestions. But don’t let that put you off: I’ll keep the offer open for anybody else who gets in touch with significant useful ideas.

Resharper 6 XAML Tip: Intellisense for your Databindings

Anybody who has installed the Resharper 6 Beta (and that should be all of you – it’s awesome, and no major problems that I can see) will find in it a feature I’ve been wanting ever since WPF was first released: intellisense for databindings.

Mark up your Xaml so that Resharper knows the type of your DataContext and it will tell you what properties you can bind to, and warn you if it doesn’t recognize what you’ve typed. I’m always switching back and forth between my Views and ViewModels to make sure I get my property names right, so this will be a real time-saver.

There are lots of places where Resharper can already deduce the type of the DataContext – within DataTemplates where you’ve specified a DataType, for example. In other cases, there's just one thing you have to do to enable this awesome feature.

At the root of your file, you need to add the d:DataContext attribute and set it to the type of you Datacontext. Here’s an example:

<UserControl x:Class="MyApp.Views.MyView"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
             xmlns:ViewModels="clr-namespace:MyApp.ViewModels"
             mc:Ignorable="d"
             d:DataContext="{d:DesignInstance ViewModels:MyViewModel, IsDesignTimeCreatable=False}">

Now if you press Ctrl-Space within a binding element, you’ll get lovely intellisense:

XmlSerializerFormat is NOT supported by WCF Rest 4.0 in Medium Trust

Here’s one for you googlers (or bingites): Using the XmlSerializerFormat attribute on methods that you expose over WCF Rest (i.e. services using the webHttpBinding) is not supported if your service is running in Medium Trust (as it most likely is if you’re using Shared Hosting, like Rackspace Cloud Sites).

This is contrary to what you might expect from reading documents like this, which say that XmlSerializer is supported in partial trust. I guess they forgot to test the webHttpBinding scenario. I should be clear: webHttpBinding itself works fine in Medium Trust: it’s using XmlSerializerFormat with webHttpBinding that will give you problems.

That’s the short story.

Here’s the amplified version.

How I learned: the hard way

I’m building a web service that my friends running MacOSX want to be able to use. Out in the Apple orchards they’re not so keen on SOAP as we are who sit behind Windows. So I turned to WCF Web Http, now part of .Net 4.0, which lets you take control of your urls and keep your messages to the bare necessities.

With WCF REST you have the choice of XML or JSON. I chose XML, and by default WCF will use the DataContractSerializer. That produces reasonably clean XML, but it is picky about ordering of elements within messages, it annotates elements with type attributes that are often unnecessary, and it has a rather clunky syntax for serializing arrays.

Then I read about the XmlSerializerFormat attribute. If you apply that to your Operation Contracts, it switches to using the XmlSerializer, and then, by decorating your data contracts with the appropriate attributes, you can take complete control of the xml which gets written to the wire.

All well and good – while the service was running on my machine. But when I pushed the bits to our web host, who run all websites under Medium Trust, it was a different story. All the calls to the service threw a ProtocolException with the helpful message: “(400) Bad Request”.

Turning on includeExceptionDetailInFaults, then spying on the interaction using Fiddler shed more light on the situation. I was getting back a stack trace with this at the top:

at System.ServiceModel.Dispatcher.UnwrappedTypesXmlSerializerManager.BuildSerializers()
   at System.ServiceModel.Dispatcher.UnwrappedTypesXmlSerializerManager.GetOperationSerializers(Object key)
   at System.ServiceModel.Dispatcher.SingleBodyParameterXmlSerializerMessageFormatter.EnsureSerializers()
   at System.ServiceModel.Dispatcher.SingleBodyParameterXmlSerializerMessageFormatter.GetInputSerializers()
   at System.ServiceModel.Dispatcher.SingleBodyParameterMessageFormatter.ReadObject(Message message)
   at System.ServiceModel.Dispatcher.SingleBodyParameterMessageFormatter.DeserializeRequest(Message message, Object[] parameters)

A bit of hunting around using Reflector revealed that the BuildSerializers method always calls XmlSerializer.FromMappings, and if you check that out on MSDN, you’ll see that it requires Full Trust.

So there’s no getting away from it. You can’t use XmlSerializer together with WebHttpBinding under Medium Trust. I did try the usual work-around for getting XmlSerializer to work in Medium Trust – pre-generating the serialization assemblies at build time: but that was before Reflector showed me the clinching evidence that my efforts were futile.

So what are your options? Either stick with DataContractSerializer, or switch to JSON¹. Or, if time is on your side, wait for the next version of WCF which has a new extensible Web API specially designed to let you take complete control of your message formats and such like.

---

1. Decorate your methods like this to switch to JSON format:

[ServiceContract()]
public interface IService
{
    [OperationContract]
    [WebInvoke(UriTemplate = "/MyOperation", 
               Method = "POST",
               RequestFormat = WebMessageFormat.Json,
               ResponseFormat = WebMessageFormat.Json)]
    Response MyOperation(Dto dto);
}

Book Review: Brilliant Freelancer

I had a pleasant surprise last Tuesday: an email from Leif Kendall congratulating me on winning a copy of his book, Brilliant Freelancer.

The vividly coloured volume duly arrived on Saturday, and on Monday kept me pleasantly occupied on a journey from Birmingham up to London, and part of the way home again, leaving me with enough time to jot down my impressions before getting off the train.

I’d recommend this book to anyone hesitating on the brink of a freelance career, or those who have just taken the plunge. If, like me, you’ve hitherto been consumed by coding, or whatever it is that specialists in your field do, Brilliant Freelancer will open your eyes to everything else that is involved in running a micro-business. But it will turn up the lights gently so you don’t get scared off the prospect for good.

The books starts by helping you think through your suitability to be a freelancer, then talks you through making the transition from employment to being your own boss. It gives advice on how to find work through sales and marketing (including chapters on blogging and networking), how to price your work, and how to manage clients when you’ve got them.

You may be be asking yourself how you’ll get anything done without a boss to crack the whip – and Leif has thoughtfully included a chapter on Motivation. If you have the opposite problem, and can’t get enough of the drug called work, Dr Kendall is there to remind you (in a chapter entitled Healthy Body, Healthy mind) that “You’re selling you, so look after your product”.

Don't think of 'marketing' as a nefarious activity conducted by spivs and double-glazing companies. Marketing means to take your goods to market. You would not consider farmers evil for taking their wares to the market, so don't consider yourself evil for doing the same.

Leif Kendall, Brilliant Freelancer

There’s one part of the book that I feel could be expanded, and that is in the financial department. Book-keeping, after all, is the one part of every business that’s mandated by law. Brilliant Freelancer does little more than skim the surface here, and at the very least could do with some recommendations for further reading.

With his easy-going style, no-nonsense advice, and flashes of humour, Leif presents himself as the wise friend who has seen it all before. He’s not afraid to point out where you’ll find the going tough, but he’s equally quick to highlight the potential rewards.

Perhaps you’ve been thinking about setting up on your own? If so, this book is for you. Check out the website (you can read a chapter for free), or buy the book on Amazon.