WebGet and WebInvoke rock!

I'm loving the new WebGet and WebInvoke programming model in WCF- the URITemplate binding style is so natural. Just poke up a request URI with some placeholders in it, and WCF magically maps it to the right operation on my contract and plugs in the arg values... It'd be even cooler if it supported something akin to WPF binding paths (allowing you to bind querystring values to any property on any object), but I'm still thrilled with what we have, especially how much better it is than the Beta1 stuff!

This being beta software, however, there are a few rough edges. Unfortunately, WebGet operations don't support nullables. That means I have to botch up my existing contracts that have "optional" int typed args to take strings (so I can distinguish missing values from default values- I get this with my enums already because I always define a 0 "Undefined" value). If you try to use a nullable in a WebGet OperationContract, you'll end up with:

Operation 'Op' in contract 'Service' has a query variable named 'nv' of type 'System.Nullable`1[System.Int32]', but type 'System.Nullable`1[System.Int32]' is not convertible by 'QueryStringConverter'. Variables for UriTemplate query values must have types that can be converted by 'QueryStringConverter'.

I've filed a suggestion to see if they can add support for nullables. Go vote for it! I guess I'm the Nullable b*tch- I went and counted. Over the years, I've filed six different bugs on various .NET APIs support for nullables, and blogged about at least one of them.

UPDATE:

The situation is worse when using enableWebScript with the JSON bits. The JsonQueryStringConverter says it supports Nullables (eg, its CanConvert method returns true when a Nullable comes in), but it barfs if the value is actually null when you call ConvertStringToValue. This is even worse- my service starts up fine, but fails with a NullReferenceException in the JSON deserializer the first time I omit a nullable value from my query string. Ick. Bug filed.