The MVC Team has today released the latest preview of the MVC Framework.

Last we got the Interim Release, which was a source refresh and not an official preview.

The previews are probably more stable in feature set, and are relatively well-tested, whereas the interim release feels more like a focus-group test with the developer community, of new ideas to the feature set that are not decided or sufficiently tested yet.

This is a great Idea - it opens for dialog, and makes me feel that we can actually still make a difference to the final product.

This Preview 3 release should probably be considered as the result of this, and I am very excited to see, what changes we are going to see.

So far i have noticed the following:

In the Interim release it was required that you return an ActionResult from an ActionMethod, this is no longer the case - you can choose either way, void or ActionResult.

Furthermore as specialized versions of an ActionResult, the following types are added:

• ViewResult: Renders the specified view to the response.
• EmptyResult: Does nothing. Returned if the action method must return a null result.
• RedirectResult: Performs an HTTP redirect to the specified URL.
• RedirectToRouteResult: Given some routing values, uses the routing API to determine the URL and then redirects to that URL.
• JsonResult: Serializes the specified ViewData object to JSON format.
• ContentResult: Writes the specified text content to the response.

Especially the JsonResult looks very interesting for Ajax scenarios.

Then we see some improvements to the HTML helper methods, and some improvements to routing, like allowing all special characters in routes and the addition of IgnoreRoute() method that lets you ignore certain URL patterns in processing.

All in all, very interesting and I am certainly going to dig deeper into this the next couple of days, getting my MVC applications up to date.

Related links

• ASP.NET MVC Preview 3 Download
• ASP.NET MVC Preview 3 Source
• ScottGu's Post

Last week I wrote a post about the IE6 VPC that is going to expire on the April 1st, with a somewhat harsh tone. Today I am glad to realize that a refreshed version has been made available for download with an expiration date of July 23^rd.

The good news is, that the VPC releases will be refreshed as long as it is necessary. The bad news is, that you need to get the new release every few months, unless you have an MSDN subscription.

The download has been reduced to just under 400 MB, and the content hasn't changed. WGA still doesn't work on the virtual machine, but if you have a specific application you need installed, let them know, an leave a comment in the Post on IEBlog and it might be adressed in future releases.

Get the new IE6 VPC

I recently upgraded to Vista on my developing machine, and it has worked like a charm. Although the other day I ran in to some problems with IIS7 , as I was going to do some work on a website that uses URL rewriting to make some nice search engine friendly URL's.

I published my project to localhost, and fired up a browser, and got the message: http-error 403.14 - forbidden as shown below (my Vista is in Danish, so these screenshots may by gibberish to you):

I had set my startpage as something like "frontpage" with no extension and on IIS6 i just set up a wildcard mapping to route any request through the aspnet_isapi.dll, and then handled the forwarding with internal logic.

Rather baffled i studied the message suspecting of course that it had something to do with wildcard mappings, so I opened the IIS Manager to take a look at the StaticFile handler that is mentioned in the error message.

In the IIS Manager choose Handler Mappings in the IIS section, and you will get the following screen, where we can see the StaticFile handler:

I noticed that it was set to match * and that got me thinking. What I need is really a wildcard match that passes all request to aspnet_isapi.dll, and as all the static files have extensions, I should set the StaticFile Handler to process *.*

So first I setup a new Script Map to map all requests to aspnet_isapi.dll - this is just like in IIS6.

Then push the "Request restrictions" button and you will get the screen below, where you unselect the Invoke handler checkbox.

When you press ok to the choices, you will be prompted to allow enabling of the ISAPI extension. Choose yes in the dialog.

Now we want to set the StaticFile Handler, that is currently reporting the error, to only handle files with an extension.

So now I think I'm good to go, and I try to launch my page again. But theres still seems to be a problem.

 As suggested in the message I consult the Event Log for an explanation, and i get this message:

A request mapped to aspnet_isapi.dll was made within an application pool running in Integrated .NET mode. Aspnet_isapi.dll can only be used when running in Classic .NET mode. Please either specify preCondition="ISAPImode" on the handler mapping to make it run only in application pools running in Classic .NET mode, or move the application to another application pool running in Classic .NET mode in order to use this handler mapping.

After some research I decide - that even though there may be better ways to create URL Rewriting with IIS7 - what I need is to get this application on the road in hurry, and therefore I go with the second option, and set the application to run in Classic .Net mode, which can be done by right-clicking the website in the IIS Manager and choosing Advanced options, and setting the App Pool to "Classic .Net AppPool" :

Again I'm optimistic and thinking that this should do the trick, and I refresh the page in the browser, but still there is something not quite right - no static files still? When I try to access an image file on the server I get the error: Failed to Execute URL.

At this point I am getting a little discouraged and I stare at the Handler Mapping Section for a while until i notice a little link in the menu in the upper right side that says: "View ordered list". Aha, I think, obviously the ordered list shows the order in which the handlers are being executed for a request.

The Wildcard script map we added earlier is at the top, and then the static files won't get processed by the StaticFile Handler. So what we need to do is, to move the Wildcard handler below the StaticFile Handler:

For some unexplainable reason I need to move the mapping twice in order for it to stay in the position. This happened again when I was going through the steps again while writing this walk-through. But second time you move it, it stays there. And voila, the page renders perfectly:

I would not recommend this approach unless you need a quick hack to simulate IIS6 setup, but as such it does the trick for me on my development station, where I do development that is deployed to non IIS7 servers. This solution is presented as is, and I give no warranty that it will solve your problem.

I don't want to start any religious feud about which browser is best, but there is one point, that is bothering me a bit.

We have been forced to utilize virtualization in order to test web applications reliably in both IE6 and IE7 on the same machine, which is a pain in my behind. Microsoft chose to release the "Internet Explorer 6 Application Compatibility VPC Image" that allows you to run a IE6 testing environment as a VPC, without getting a license for that second install of Windows XP.

This release is of course something by way of compensation, but to my great astonishment i realize that this image expires on April 1 2007. If you look at some statistics IE6 is still the most used browser - im not sure this is a completely accurate statistic, but that doesn't matter - the point is, that IE6 is still widely used, and we as developers need to test our applications on IE6 even after the VPC expires.

I don't know about you, but I will sure feel like an Aprils Fool when this happens. I sure hope for Microsoft that they release a new version with an extended licence.