A slew of problems

I (too) hastily upgraded from what was code-named “Visual Studio 11” to what’s now called “Visual Studio 2012” (RC) and ran into a bunch of issues that pretty much ruined productivity for the day. Lesson from the wise, don’t always circle the bright shiny objects!

Here’s a summary of the lessons learned (thus far) with many thanks to the few who went before and thoughtfully documented their learnings too.

MissingMethodException

After installing and compiling the Azure Data Market companion project to feetens, I received this exception. Thanks to Kamran’s ,Tips for Updating from Web API Beta to Web API RC, I was soon aware that I shot myself in the foot by upgrading to Web API RC as part of the Visual Studio 2012 RC install. I dithered as I looked through Kamran’s long list of potential consequences but realized that, by delaying, I would only be delaying the inevitable. I recommend reading his post for detailed instructions on how to perform the upgrade using NuGet correctly.

Passing complex types to Web API

The next problem which almost ruined my week was an apparent breaking change in the way that Web API binds to parameters. Previously (beta), this has closely followed MVC’s model binding approach (which is excellent) but, presumably for good reasons, Microsoft’s decided to cleave some space between these two approaches. The result was, my recent efforts at Sending JavaScript arrays of array to Web API broke. The error was clear, that the engine was unable to find a matching method and, debugging, quickly identified the problem. My heart sank because it appeared that I’d have to draft a model binder for this specific case . The ASP.NET forums carried several questions about these changes but imran_ku07’s enigmatic recommendation worked!

public IEnumerable<Crime> Get([FromUri]IEnumerable<State> states)

jQuery AJAX content-type

What could have been a real stumbler was quickly resolved. I was receiving an  System.InvalidOperationException stating that “No MediaTypeFormatter is available to read an object of type ‘IEnumerable`1’ from content with media type ”undefined”. Interesting the “FromUri” attribute fix for complex types also resolves this issue. However, before finding imran_ku07’s answer, I diagnosed this problem as a result of sending the following contentType to the service

$.ajaxSetup({
    dataType: "json",
    contentType: "application/json: charset=utf-8"...

I found an immediate resolution in this blog post which lists the default Web API formatters and includes “application/json” but apparently nothing that would match the additional charset. After adjusting the content type per below, the exception no longer arose but, as I say, it was the “FromUri” attribute that was the ultimate fix.

$.ajaxSetup({
    dataType: "json",
    contentType: "application/json"...

Anti-Forgery Tokens

If you follow mabbled’s blog, you may have read about the obscure error involving iPrincipal naming that resulted from the combination of MVC’s anti-forgery infrastructure and WIF’s claims-based authentication. Having endured the problems described above, I tried feetens only to discover yet another problem when it encountered the @Html.AntiForgeryToken() helper on its index page. The error was very descriptive. Possibly the most descriptive/clear error message that I’ve ever encountered!

A claim of type ‘http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier‘ or ‘http://schemas.microsoft.com/accesscontrolservice/2010/07/claims/identityprovider‘ was not present on the provided ClaimsIdentity. To enable anti-forgery token support with claims-based authentication, please verify that the configured claims provider is providing both of these claims on the ClaimsIdentity instances it generates. If the configured claims provider instead uses a different claim type as a unique identifier, it can be configured by setting the static property AntiForgeryConfig.UniqueClaimTypeIdentifier.

Having encountered a sibling of this problem previously, I zeroed in very quickly on the source of the problem and, with the addition of 2 lines of code, resolved it!

ci.Claims.Add(new Claim(ClaimTypes.NameIdentifier, ...));
ci.Claims.Add(new Claim(IdentityProvider, ...));

I have some anxiety that I’ve not yet encountered all the problems that the RC and my haste have created for me but, at least I’ve made good progress rectifying the current slew of problems today. Wish me luck!