They say that writing a book is a hard way to make an easy living. This is especially true for technical books, which tend to have a short shelf life.
For me, the process was made easier by having three great seasoned authors to work with. We updated all the existing chapters of this 4th edition to cover ASP.NET MVC 4, and we've added three new chapters covering Membership & Security, Web API, and the building of the NuGet Gallery site using MVC. I like to think of this book as my Microsoft swan song. :)
Norway is a great place to visit, and the Norwegian Developers Conference was one of the best conferences I've ever been to (it's no coincidence, I think, that my two favorite conferences are both in northern Europe: NDC and Oredev).
Update: The Web API team is planning to add this to v2. Please visit the Wiki and give feedback!
While there is no batching standard built into the HTTP protocol, there is a standard for MIME encoding HTTP request and response messages ("application/http" with "msgtype=request" and "msgtype=response", respectively). ASP.NET Web API has built-in support for both MIME multipart as well as encoded request and response messages, so we have all the building blocks we need to make a simple batch request handler.
I know we left off in part 3 with a problem, but we're not going to solve it yet, because we still need to build some foundation helper classes that will make it easier to do that. In particular, there are some good practices we can codify around the creation and conversion of tasks that led us to write the TaskHelpers class that we use today in ASP.NET Web Stack.
I promised that we had a bug in our previous code, and we did... sort of. Calling ContinueWith without any special flags will cause your continuation to always run, regardless of the final state of the task. We wrote our continuation under the assumption that the Task had completed successfully, which can lead to some very odd and hard to debug problems. Luckily, in our code, we ended up calling Result on the Task object, which turns around and throws an exception if the task had ended in a faulted or canceled state. But what if we'd had a Task rather than a Task<T>? Or what if we hadn't called Result? In .NET 4, this is considered a fatal error condition, and when the task object got garbage collected, its finalizer would've thrown an exception that takes down your AppDomain because you had an unobserved fault! Definitely not good.
An important part of the work in properly handling tasks on the server is supporting the synchronization context. When you’re using .NET 4.5, then the await keyword automatically does this for you. When you’re consuming Task objects on .NET 4, though, getting yourself back onto the right synchronization context is critical; otherwise, you may cause errors in your application when trying to access things which touch the HttpContext in ASP.NET.
Asynchronous (multi-threaded) programming is not easy.
This warning really has nothing to do with .NET in particular, because it can be quite challenging to do correctly on any framework, but here’s the good news:
Asynchronous programming with .NET 4 is a little easier. Asynchronous programming with .NET 4.5 is a lot easier.
A few months ago, I finished writing part of a book on ASP.NET MVC 3. I was honored to be asked to write the third edition of the book with fellow co-workers Phil Haack and Jon Galloway, and incredibly smart dude K. Scott Allen. This is very good company to be in for a first-time author. :)
The first edition of this book was written by some very impressive people, and it got terrific reviews. The second edition was mostly the same as the first. We took the feedback from the 2nd edition and decided that potential customers would appreciate it if we re-examined the structure of the book and provide as much new content as possible.