Maarten Balliauw {blog}

Thursday evening, I did a session on Mocking for the VISUG (Visual Studio User Group Belgium). As promised, here is the slide deck I’ve used. The session will be available online soon, in the meantime you'll have to go with the slide deck.

Demo code can also be downloaded: MockingDemoCode.zip (1.64 mb)

Thank you for attending the session!

In this post, I’ll share some of the best practices and guidelines which I have come across while developing ASP.NET MVC web applications. I will not cover all best practices that are available, instead add some specific things that have not been mentioned in any blog post out there.

Existing best practices can be found on Kazi Manzur Rashid’s blog and Simone Chiaretta’s blog:

• ASP.NET MVC Best Practices (part 1)
• ASP.NET MVC Best Practices (part 2)
• How to improve the performance of ASP.NET MVC web applications?

After reading the best practices above, read the following best practices.

Use model binders where possible

I assume you are familiar with the concept of model binders. If not, here’s a quick model binder 101: instead of having to write action methods like this (or a variant using FormCollection form[“xxxx”]):

You can now write action methods like this:

Or even cleaner:

What’s the point of writing action methods using model binders?

• Your code is cleaner and less error-prone
• They are LOTS easier to test (just test and pass in a Person)

Be careful when using model binders

I know, I’ve just said you should use model binders. And now, I still say it, except with a disclaimer: use them wisely! The model binders are extremely powerful, but they can cause severe damage…

Let’s say we have a Person class that has an Id property. Someone posts data to your ASP.NET MVC application and tries to hurt you: that someone also posts an Id form field! Using the following code, you are screwed…

Instead, use blacklisting or whitelisting of properties that should be bound where appropriate:

Or whitelisted (safer, but harder to maintain):

Yes, that can be ugly code. But…

• Not being careful may cause harm
• Setting blacklists or whitelists can help you sleep in peace

Never re-invent the wheel

Never reinvent the wheel. Want to use an IoC container (like Unity or Spring)? Use the controller factories that are available in MvcContrib. Need validation? Check xVal. Need sitemaps? Check MvcSiteMap.

Point is: reinventing the wheel will slow you down if you just need basic functionality. On top of that, it will cause you headaches when something is wrong in your own code. Note that creating your own wheel can be the better option when you need something that would otherwise be hard to achieve with existing projects. This is not a hard guideline, you’ll have to find the right balance between custom code and existing projects for every application you’ll build.

Avoid writing decisions in your view

Well, the title says it all.. Don’t do this in your view:

Instead, do this in your controller:

Ok, the first example I gave is not that bad if it only contains one paragraph… But if there are many paragraphs and huge snippets of HTML and ASP.NET syntax involved, then use the second approach. Really, it can be a PITA when having to deal with large chunks of data in an if-then-else structure.

Another option would be to create a HtmlHelper extension method that renders partial view X when condition is true, and partial view Y when condition is false. But still, having this logic in the controller is the best approach.

Don’t do lazy loading in your ViewData

I’ve seen this one often, mostly by people using Linq to SQL or Linq to Entities. Sure, you can do lazy loading of a person’s orders:

This Count() method will go to your database if model is something that came out of a Linq to SQL data context… Instead of doing this, retrieve any value you will need on your view within the controller and create a model appropriate for this.

Note: This one is really for illustration purpose only. Point is not to pass the datacontext-bound IQueryable to your view but instead pass a List or similar.

And the view for that:

Motivation for this is:

• Accessing your data store in a view means you are actually breaking the MVC design pattern.
• If you don't care about the above: when you are using a Linq to SQL datacontext, for example, and you've already closed that in your controller, your view will error if you try to access your data store.

Put your controllers on a diet

Controllers should be really thin: they only accept an incoming request, dispatch an action to a service- or business layer and eventually respond to the incoming request with the result from service- or business layer, nicely wrapped and translated in a simple view model object.

In short: don’t put business logic in your controller!

Compile your views

Yes, you can do that. Compile your views for any release build you are trying to do. This will make sure everything compiles nicely and your users don’t see an “Error 500” when accessing a view. Of course, errors can still happen, but at least, it will not be the view’s fault anymore.

Here’s how you compile your views:

1. Open the project file in a text editor. For example, start Notepad and open the project file for your ASP.NET MVC application (that is, MyMvcApplication.csproj).

2. Find the top-most <PropertyGroup> element and add a new element <MvcBuildViews>:

3. Scroll down to the end of the file and uncomment the <Target Name="AfterBuild"> element. Update its contents to match the following:

4. Save the file and reload the project in Visual Studio.

Enabling view compilation may add some extra time to the build process. It is recommended not to enable this during development as a lot of compilation is typically involved during the development process.

More best practices

There are some more best practices over at LosTechies.com. These are all a bit advanced and may cause performance issues on larger projects. Interesting read but do use them with care.

As promised to all people attending my online session on ASP.NET MVC this afternoon, here is the slide deck I’ve used.

I must say, doing a presentation using Live Meeting and a Microsoft Roundtable device seemed a bit strange at first. However, the setup that is used to do this kind of sessions is really cool to work with! Make sure to check Katrien’s blog for all other Live Meeting MSDN sessions that are planned.

Microsoft’s Managed Extensibility Framework (MEF) is a .NET library (released on CodePlex) that enables greater re-use of application components. You can do this by dynamically composing your application based on a set of classes and methods that can be combined at runtime. Think of it like building an appliation that can host plugins, which in turn can also be composed of different plugins. Since examples say a thousand times more than text, let’s go ahead with a sample leveraging MEF in an ASP.NET MVC web application.

Getting started…

The Managed Extensibility Framework can be downloaded from the CodePlex website. In the download, you’ll find the full source code, binaries and some examples demonstrating different use cases for MEF.

Now here’s what we are going to build: an ASP.NET MVC application consisting of typical components (model, view, controller), containing a folder “Plugins” in which you can dynamically add more models, views and controllers using MEF. Schematically:

Creating a first plugin

Before we build our host application, let’s first create a plugin. Create a new class library in Visual Studio, add a reference to the MEF assembly (System.ComponentModel.Composition.dll) and to System.Web.Mvc and System.Web.Abstractions. Next, create the following project structure:

That is right: a DemoController and a Views folder containing a Demo folder containing Index.aspx view. Looks a bit like a regular ASP.NET MVC application, no? Anyway, the DemoController class looks like this:

Nothing special, except… what are those three attributes doing there, Export and PartCreationPolicy? In short:

• Export tells the MEF framework that our DemoController class implements the IController contract and can be used when the host application is requesting an IController implementation.
• ExportMetaData provides some metadata to the MEF, which can be used to query plugins afterwards.
• PartCreationPolicy tells the MEF framework that it should always create a new instance of DemoController whenever we require this type of controller. By defaukt, a single instance would be shared across the application which is not what we want here. CreationPolicy.NonShared tells MEF to create a new instance every time.

Now we are ready to go to our host application, in which this plugin will be hosted.

Creating our host application

The ASP.NET MVC application hosting these plugin controllers is a regular ASP.NET MVC application, in which we’ll add a reference to the MEF assembly (System.ComponentModel.Composition.dll). Next, edit the Global.asax.cs file and add the following code in Application_Start:

What we are doing here is telling the ASP.NET MVC framework to create controller instances by using the MefControllerFactory instead of ASP.NET MVC’s default DefaultControllerFactory. Remember that everyone’s always telling ASP.NET MVC is very extensible, and it is: we are now changing a core component of ASP.NET MVC to use our custom MefControllerFactory class. We’re also telling our own MefControllerFactory class to check the “Plugins” folder in our web application for new plugins. By the way, here’s the code for the MefControllerFactory:

Too much? Time for a breakdown. Let’s start with the constructor:

In the constructor, we are storing the path where plugins can be found (the “Plugins” folder in our web application). Next, we are telling MEF to create a catalog of plugins based on what it can find in that folder using the DirectoryCatalog class. Afterwards, a CompositionContainer is created which will be responsible for matching plugins in our application.

Next, the CreateController method we need to implement for IControllerFactory:

This method handles the creation of a controller, based on the current request context and the controller name that is required. What we are doing here is checking MEF’s container for all “Exports” (plugins as you wish) that match the controller name. If one is found, we return that one. If not, we’re falling back to ASP.NET MVC’s DefaultControllerBuilder.

The ReleaseController method is not really exciting: it's used by ASP.NET MVC to correctly dispose a controller after use.

Running the sample

First of all, the sample code can be downloaded here: MvcMefDemo.zip (270.82 kb)

When launching the application, you’ll notice nothing funny. That is, untill you want to navigate to the http://localhost:xxxx/Demo URL: there is no DemoController to handle that request! Now compile the plugin we’ve just created (in the MvcMefDemo.Plugins.Sample project) and copy the contents from the \bin\Debug folder to the \Plugins folder of our host application. Now, when the application restarts (for example by modifying web.config), the plugin will be picked up and the http://localhost:xxxx/Demo URL will render the contents from our DemoController plugin:

Conclusion

The MEF (Managed Extensibility Framework) offers a rich manner to dynamically composing applications. Not only does it allow you to create a plugin based on a class, it also allows exporting methods and even properties as a plugin (see the samples in the CodePlex download).

By the way, sample code can be downloaded here: MvcMefDemo.zip (270.82 kb)

Last week, I blogged about all stuff that is included in the ASP.NET MVC Futures assembly, which is an assembly available on CodePlex and contains possible future features (tonguetwister!) for the ASP.NET MVC framework. One of the comments asked for more information on the AsyncController that is introduced in the MVC Futures. So here goes!

Asynchronous pages

The AsyncController is an experimental class to allow developers to write asynchronous action methods. But… why? And… what? I feel a little confusion there. Let’s first start with something completely different: how does ASP.NET handle requests? ASP.NET has 25 threads(*) by default to service all the incoming requests that it receives from IIS. This means that, if you have a page that requires to work 1 minute before returning a response, only 25 simultaneous users can access your web site. In most situations, this occupied thread will just be waiting on other resources such as databases or webservice, meaning it is actualy waiting without any use while it should be picking up new incoming requests.

(* actually depending on number of CPU’s and some more stuff, but this is just to state an example…)

In ASP.NET Webforms, the above limitation can be worked around by using the little-known feature of “asynchronous pages”. That <%@ Page Async="true" ... %> directive you can set in your page is not something that had to do with AJAX: it enables the asynchronous page processing feature of ASP.NET Webforms. More on how to use this in this article from MSDN magazine. Anyway, what basically happens when working with async pages, is that the ASP.NET worker thread fires up a new thread, assigns it the job to handle the long-running page stuff and tells it to yell when it’s done so that the worker thread can return a response to the user. Let me rephrase that in an image:

I hope you see that this pattern really enables your web server to handle more requests simultaneously without having to tweak standard ASP.NET settings (which may be another performance tuning thing, but we will not be doing that in this post).

AsyncController

The ASP.NET MVC Futures assembly contains an AsyncController class, which actually mimics the pattern described above. It’s still experimental and subject to change (or to disappearing), but at the moment you can use it in your application. In general, the web server schedules a worker thread to handle an incoming request. This worker thread will start a new thread and call the action method on there. The worker thread is now immediately available to handle a new incoming request. Sound a bit the same as above, no? Here’s an image of the AsyncController flow:

Now you know the theory, let’s have a look at how to implement the AsyncController pattern…

Preparing your project…

Before you can use the AsyncController, some changes to the standard “File > New > MVC Web Application” are required. Since everything I’m talking about is in the MVC Futures assembly, first grab the Microsoft.Web.Mvc.dll at CodePlex. Next, edit Global.asax.cs and change the calls to MapRoute into MapAsyncRoute, like this:

No need to worry: all existing synchronous controllers in your project will keep on working. The MapAsyncRoute automatically falls back to MapRoute when needed.

Next, fire up a search-and-replace on your Web.config file, replacing

with:

If you now inherit all your controllers from AsyncController instead of Controller, you are officially ready to begin some asynchronous ASP.NET MVC development.

Asynchronous patterns

Ok, that was a lie. We are not ready yet to start asynchronous ASP.NET MVC development. There’s a choice to make: which asynchronous pattern are we going to implement?

The AsyncController offers 3 distinct patterns to implement asynchronous action methods.. These patterns can be mixed within a single AsyncController, so you actually pick the one that is appropriate for your situation. I’m going trough all patterns in this blog post, starting with…

The IAsyncResult pattern

The IAsyncResult pattern is a well-known pattern in the .NET Framework and is well documened on MSDN. To implement this pattern, you should create two methods in your controller:

Let’s implement these methods. In the BeginIndexIAsync method, we start reading a file on a separate thread:

Now, in the EndIndexIAsync action method, we can fetch the results of that operation and return a view based on that:

Note that standard model binding takes place for the normal parameters of the BeginIndexIAsync method. Only filter attributes placed on the BeginIndexIAsync method are honored: placing these on the EndIndexIAsync method is of no use.

The event pattern

The event pattern is a different beast. It also consists of two methods that should be added to your controller:

Let’s implement these and have a look at the details. Here’s the IndexEvent method:

We’ve just seen how you can pass a parameter to the IndexEventCompleted action method. The next thing to do is tell the AsyncManager how many outstanding operations there are. If this count becomes zero, the IndexEventCompleted  action method is called.

Next, we can consume the results just like we could do in a regular, synchronous controller:

I really think this is the easiest-to-implement asynchronous pattern available in the AsyncController.

The delegate pattern

The delegate pattern is the only pattern that requires only one method in the controller. It basically is a simplified version of the IAsyncResult pattern. Here’s a sample action method, no further comments:

Conclusion

First of all, you can download the sample code I have used here: MvcAsyncControllersExample.zip (64.24 kb)

Next, I think this is really a feature that should be included in the next ASP.NET MVC release. It can really increase the number of simultaneous requests that can be processed by your web application if it requires some longer running I/O code that otherwise would block the ASP.NET worker thread. Development is a little bit more complex due to the nature of multithreading: you’ll have to do locking where needed, work with IAsyncResult or delegates, …

In my opinion, the “event pattern” is the way to go for the ASP.NET MVC team, because it is the most readable. Also, there’s no need to implement IAsyncResult classes for your own long-running methods.

Hope this clarified AsyncControllers a bit. Till next time!

Some Great news (at least: I think this is great :-)): Kevin Dockx and I will be giving a session on PHP and Silverlight at the Netherlands DevDays09. This event, aimed totally at developers, will take place on May 28 and 29th in The Hague (Den Haag). It’s the first time the DevDays are hosting sessions related to PHP, and it’s also the first time I’ll be speaking at an event of this size.

Our session will cover the basics of Silverlight and show you how you can create rich web applications using the best of 2 worlds: Silverlight and PHP.

Next to this event, we’ll be doing this very same session at the Dutch PHP Conference in Amsterdam, which will take place June 11 – June 13th. Yes, we are evil, doing a presentation on Microsoft technologies at a PHP event.

And now that I’m announcing upcoming sessions anyway… I’ll be doing a session on mocking at VISUG (Visual Studio User Group Belgium). Come visit us at May 7th! This session will show you the basics of unit testing without having to rely on external dependencies like databases, WCF services, ... and will show you how you can reproduce behaviour in a unit test that might be otherwide difficult to test.

Oh, and another one: MSDN Belgium is hosting some virtual events. I’ll be doing a session on the ASP.NET MVC framework (in Dutch) on April 23 at 14:00. Check the MSDN pages for more info (yet to come). Here’s the abstract of that session:

"Join us for this 90 min session and get a developer-focused overview on ASP.NET MVC (Model-View-Controller), a new approach in building ASP.NET applications. Learn how the new ASP.NET MVC framework differs and can be an alternative to the current ASP.NET Web Forms framework. This session will help you to learn how to take advantage of ASP.NET MVC to build loosely coupled, highly testable, agile applications. You will see how ASP.NET MVC provides you with fine-grained control over both HTML and JavaScript."

For those of you who did not know yet: next to the ASP.NET MVC 1.0 version and its source code, there’s also an interesting assembly available if you can not wait for next versions of the ASP.NET MVC framework: the MVC Futures assembly. In this blog post, I’ll provide you with a quick overview of what is available in this assembly and how you can already benefit from… “the future”.

First things first: where to get this thing? You can download the assembly from the CodePlex releases page. Afterwards, reference this assembly in your ASP.NET MVC web application. Also add some things to the Web.config file of your application:

You are now ready to go! Buckle up and start your De Lorean DMC-12…

Donut caching (a.k.a. substitution)

If you have never heard of the term “donut caching” or “substitution”, now is a good time to read a previous blog post of mine. Afterwards, return here. If you don’t want to click that link: fine! Here’s in short: “With donut caching, most of the page is cached, except for some regions which are able to be substituted with other content.”

You’ll be needing an OutputCache-enabled action method in a controller:

Next: a view. Add the following lines of code to a view:

There you go: when running this application, you will see one DateTime printed in a cached way (refreshed once a minute), and one DateTime printed on every page load thanks to the substitution HtmlHelper extension. This extension method accepts a HttpContext instance which you can also use to enhance the output.

Now before you run away and use his in your projects: PLEASE, do not do write lots of code in your View. Instead, put the real code somewhere else so your view does not get cluttered and your code is re-usable. In an ideal world, this donut caching would go hand in hand with our next topic…

Render action methods inside a view

You heard me! We will be rendering an action method in a view. Yes, that breaks the model-view-controller design pattern a bit, but it gives you a lot of added value while developing applications! Look at this like “partial controllers”, where you only had partial views in the past. If you have been following all ASP.NET MVC previews before, this feature already existed once but has been moved to the futures assembly.

Add some action methods to a Controller:

This indeed is not much logic, but here’s the point: the SomeAction action method will render a view. That view will then render the CurrentTime action method, which will also render a (partial) view. Both views are combined and voila: a HTTP response which was generated by 2 action methods that were combined.

Here’s how you can render an action method from within a view:

There’s also lambdas to perform more complex actions!

What most people miss: controls

Lots of people are missing something when first working with the ASP.NET MVC framework: “Where are all the controls? Why don’t all ASP.NET Webforms controls work?” My answer would normally be: “You don’t need them.”, but I now also have an alternative: “Use the futures assembly!”

Here’s a sample controller action method:

The view:

As you can see: these controls all work quite easy. The "Name property accepts the key in the ViewData dictionary and will render the value from there. In the repeater control, you can even work with “good old” Eval: <%# Eval("Name") %>.

Extra HtmlHelper extension methods

Not going in too much detail here: there are lots of new HtmlHelper extension methods. The ones I especially like are those that allow you to create a hyperlink to an action method using lambdas:

Here’s a list of new HtmlHelper extension methods:

• ActionLink – with lambdas
• RouteLink – with lambdas
• Substitute (see earlier in this post)
• JavaScriptStringEncode
• HiddenFor, TextFor, DropDownListFor, … – like Hidden, Text, … but with lambdas
• Button
• SubmitButton
• Image
• Mailto
• RadioButtonList
• …

More model binders

Another thing I will only cover briefly: there are lots of new ModelBinders included! Model binders actually allow you to easily map input from a HTML form to parameters in an action method. That being said, here are the new kids on the block:

• FileCollectionModelBinder – useful for HTTP posts that contain uploaded files
• LinqBinaryModelBinder
• ByteArrayModelBinder

When you want to use these, do not forget to register them with ModelBinders.Binders in your Global.asax.

More ActionFilters and ResultFilters

Action filters and result filters are used to intercept calls to an action method or view rendering, providing a hook right before and after that occurs. This way, you can still modify some variables in the request or response prior to, for example, executing an action method. Here’s what is new:

• AcceptAjaxAttribute – The action method is only valid for AJAX requests. It allows you to have different action methods for regular requests and AJAX requests.
• ContentTypeAttribute – Sets the content type of the HTTP response
• RequireSslAttribute – Requires SSL for the action method to execute. Allows you to have a different action method for non-SSL and SSL requests.
• SkipBindingAttribute – Skips executing model binders for an action method.

Asynchronous controllers

This is a big one, but it is described perfectly in a Word document that can be found on the MVC Futures assembly release page. In short:

The AsyncController is an experimental class to allow developers to write asynchronous action methods. The usage scenario for this is for action methods that have to make long-running requests, such as going out over the network or to a database, and don’t want to block the web server from performing useful work while the request is ongoing.

In general, the pattern is that the web server schedules Thread A to handle some incoming request, and Thread A is responsible for everything up to launching the action method, then Thread A goes back to the available pool to service another request. When the asynchronous operation has completed, the web server retrieves a Thread B (which might be the same as Thread A) from the thread pool to process the remainder of the request, including rendering the response. The diagram below illustrates this point.

Sweet! Should speed up your ASP.NET MVC web application when it has to handle much requests.

Conclusion

I hope you now know what the future for ASP.NET MVC holds. It’s not sure all of this will ever make it into a release, but you are able to use all this stuff from the futures assembly. If you are too tired to scroll to the top of this post after reading it, here’s the link to the futures assembly again: MVC Futures assembly

If you have been using the ASP.NET MVC framework, you possibly have been searching for something like the classic ASP.NET sitemap. After you've played with it, you even found it useful! But not really flexible and easy to map to routes and controllers. To tackle that, last year, somewhere in August, I released a proof-of-concept sitemap provider for the ASP.NET MVC framework on my blog.

The blog post on sitemap provider I released back then has received numerous comments, suggestions, code snippets, … Together with Patrice Calve, we’ve released a new version of the sitemap provider on CodePlex: MvcSiteMap.

This time I’ll not dive into implementation details, but provide you with some of the features our sitemap provider erm… provides.

First things first: registering the provider

After downloading (and compiling) MvcSiteMap, you will have to add a reference to the assembly in your project. Also, you will have to register the provider in your Web.config file. Add the following code somewhere in the <system.web> section:

We’ve just told ASP.NET to use the MvcSiteMap sitemap provider, read sitemap nodes from the Web.sitemap file, use secrity trimming and cache the nodes for 10 minutes.

Defining sitemap nodes

Defining sitemap nodes is quite easy: add a Web.sitemap file to your project and popukate it with some nodes. Here’s an example:

Too much info? Let’s break it down. The sitemap consists of several nodes, defined by using a <mvcSiteMapNode> element. Each node can contain other nodes, as you can see in the above example. A node should also define some attributes: title and controller. Title is used by all sitemap controls of ASP.NET, controller is used to determine the controller to link to. Here’s a list of possible attributes:

Regarding the wildcard (*), here’s a sample sitemap node:

This node will map to the URL http://…./About/Contact/Maarten.

Using the sitemap

We can, for example, add breadcrumbs to our master page. Here’s how:

Looks exactly like ASP.NET Webforms, no?

Dynamic parameters

In the table mentioned above, you may have seen the isDynamic and dynamicParameters attributes. This may sound a bit fuzzy, but it’s actually quite a powerful feature. Consider the following sitemap node:

This node will actually be used by the sitemap controls when any URL refering /Products/Details/… is called:

• http://…./Products/Details/1234
• http://…./Products/Details/5678
• http://…./Products/Details/9012
• …

No need for separate sitemap nodes for each of the above URLs! One node is enough to provide your users with a consistent breadcrumb showing their location in your web application.

The MvcSiteMapNode attribute

Who said sitemaps should always be completely defined in XML? Why not use the MvcSiteMapNode attribute we created:

We are simply telling the MvcSiteMap sitemap provider to add a child node to the node with key “ProductsListCategory” which should have the title “Product details”. Controller and action are simply determined by the sitemap provider, based on the action method this attribute is declared on. Dynamic parameters also work here, by the way.

Do you have an example?

Yes! Simply navigate to the MvcSiteMap project page on CodePlex and grab the latest source code. The sitemap provider is included as well as an example website demonstrating all features.

Here’s a shameless, commercial blogpost… With yesterday’s 1.0 release of the ASP.NET MVC framework, I’m sure the following sample chapter from my book ASP.NET MVC 1.0 Quickly will be of use for people starting ASP.NET MVC development: Your first ASP.NET MVC application.

When downloading and installing the ASP.NET MVC framework SDK, a new project template is installed in Visual Studio. This chapter describes how to use the ASP.NET MVC project template that is installed in Visual Studio. All ASP.NET MVC aspects are touched briefly by creating a new ASP.NET MVC web application based on this Visual Studio template. Besides view, controller, and model, new concepts including ViewData—a means of transferring data between controller and view, routing—the link between a web browser URL and a specific action method inside a controller, and unit testing of a controller are also illustrated here.

In this chapter, you will:

• Have an overview of all the aspects of an ASP.NET MVC web application
• Explore the ASP.NET MVC web application project template that is installed in Visual Studio 2008
• Create a first action method and corresponding view
• Create a strong-typed view
• Learn how a controller action method can pass strong-typed ViewData to the view
• Learn what unit testing is all about, and why it should be used
• Learn how to create a unit test for an action method by using Visual Studio's unit test generation wizard and modifying the unit test code by hand

Download the free sample chapter here. Or order the full book, here. That’s a better option ;-)

By the way, if you are interested in the book writing process itself, check my previous blog post on that.

To keep up with a good tradition (see here and here), I have some great news on ASP.NET MVC: we are at version 1.0! This means production ready, supported, stable, …! Grab the download at Microsoft.com.

I’m expecting an epic blog post by the Gu, but here’s some stuff you may want to have a look at: all my posts on ASP.NET MVC.

Another thing you can do: order my book on ASP.NET MVC :-) We’ve released the print version yesterday, meaning you are now completely set to start developing with ASP.NET MVC.

Edit: Looks like Simone was equally fast :-) And Kris.
Edit: More from MIX: Silverlight 3 SDK Beta 1 is already up! http://tinyurl.com/crfogs