If you’re trying to build REST-enabled services with WCF, you’ll want to use the webHTTP Binding.
This binding defaults to anonymous handling, so if you’re planning on doing any authorization you need to change the binding configuration.
This took me ages to figure out, largely because the webHttp binding is new and not well documented.
To change the binding to support NTLM or Windows authentication, add the following node to the system.servicemodel in your app.config:
Note that you can supply one of five values to the mode attribute: None, Basic, Digest Windows, NTLM, and Certificate.
Once you’ve picked the one you want, in your service definition, specify your new binding from the bindingConfiguration attribute:
And all calls to your REST service should be made with a valid windows network identity.
In your serviceCode, you can retrieve it from the System.ServiceModel namespace:
Oh, and if you’re not comfortable with editing the XML files, or you’d like to explore the dizzying array of other available options in WCF, I also discovered the Microsoft Service Configuration Editor (possibly someone had discovered it before me. ) It lives at C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\SvcConfigEditor.exe. It gives you a simple(ish) visual way to edit WCF Configuration files.
UPDATE: JustinJSmith over at The Cybertopian Chronicle points out that it’s even easier to invoke the config editor – you just right click on your app.config, and select “Edit WCF Configuration” (duh…)
James Newton-King, developer of the JSON.NET project, notes that it gets harder to be a .NET developer with every release. He reposted a chart from Brad Abrams showing the growth of the number of types in the Microsoft .NET framework.
We’ve run into this problem all the time developing infovark. Often, it’s not the sheer size of the framework that proves challenging, but finding just the right method to do just the right thing.
A case in point was a recent problem I had in converting a DateTime object into a string properly formatted for XML. Normally you’d do something like this:
string theDateString = myDateTime.ToString();
This gives you a string in the .NET format, but that’s not the correct format for XML Schema (XSD). No problem, you think, I’ll just pass a format argument to the ToString method. So you look up the available string formatting options on MSDN. There’s lots of choices here, from the “based on ISO 8601″ format to the “RFC1123Pattern” to the “UniversalSortableDateTimePattern”. But it turns out that none of these formats work for XML if you want it to validate against your XML Schema. What gives? Do you have to provide a custom formatting string to get the date pattern you want?
It turns out that you’re looking in the wrong place entirely. These aren’t the string formats you’re looking for. Move along.
What you want is in the System.Xml namespace. You want the XmlConvert class. The XmlConvert class lets you convert from native .NET types to valid XML and back. The code looks like this:
string theDateString = XmlConvert.ToString(myDateTime);
It’s not only the size of the .NET framework that’s daunting. It’s the fact that functionality can be duplicated — or worse — made just slightly different across all of those classes. It puts developers in an awkward situation. Do they spend time researching to figure out exactly which method of which class in which namespace ought to be used in a given situation? Or do they roll their own (possibly buggy) implementation? It’s a tough call.
Personally, I’d like to see more guidance from Microsoft — perhaps through their code analysis tools — as to the preferred way of doing common tasks.
Thanks for stopping by!
The Infovark Underground is a new blog where Dean and I can unleash our inner nerd, and share some of the technology and experiences we run into as we build Infovark (Yes, we call our product Infovark. It’s got the same name as our company, because we’re all about making things easy to remember and share..)
Unlike our Infovark blog, which details what we’re doing, the underground will get into much more technical detail about how we’re doing it — discussing programming, development and tools.
If that sounds like the kind of stuff you might be interested in, feel free to add our feed to your readers!