Upgrading Your MVC3 Application from Preview 1 to Beta

By On October 6, 2010 · 4 Comments

By now, you’ve no doubt heard that MVC has reached the Beta milestone, and with it, some Preview 1 features have been improved, and some other great features have been announced.

I’ve been working on an MVC3 site since Preview 1, and recently completed the exercise of migrating that site from the Preview 1 bits to the Beta. It was a pretty straightforward upgrade, but I thought I would outline the specific changes I made in the hope that it will provide a time-saver to anyone else running a Preview 1 site.

Here are the things I changed in my app to get from Preview 1 to the Beta. Leave a comment if you’ve done the same and have anything to add that I don’t mention here.

 

1) IMvcServiceLocator –> IDependencyResolver

The first thing you’ll no doubt notice, is that the IMvcServiceLocator interface is no longer part of the new System.Web.Mvc Assembly. That interface has been replaced by the new IDependencyResolver interface, which has only two methods you need to implement for your specific IoC container:

 

If you implemented IMvcServiceLocator in a Preview 1 application, change the interface to use IDependencyResolver. IMvcServiceLocator specified a GetService() method, so you’ll be able to leave that method unchanged. The IEnumerable<object> GetAllInstances(Type serviceType) method specified by IMvcServiceLocator is now IEnumerable<object> GetServices(Type serviceType), so you should be able to take the code from the original method and change it to implement GetServices. The remaining methods can be removed.

Here’s my implementation for IDependencyResolver for use with StructureMap:

 

2) MvcServiceLocator –> DependencyResolver

The second thing I needed to do was to change one line in Global.asax.cs. In Preview 1, I had the following line in Application_Start():

In the beta, the MvcServiceLocator type has been replaced by DependencyResolver, so you can replace the line above with the following: 

 

3) Views/Web.config and Root Web.config

Whether or not you implemented any of the DI support in Preview 1, you will need to make some changes to your existing Web.config files (at the application root and in the Views directory). For this step, I created a new empty MVC3 application in a separate instance of VS 2010, and copied the relevant new entries into my existing application.

The Views/Web.config now should include a new system.web.webPages.razor confiruation section, which looks like this:

Unless you’ve modified your Views/Web/config, you should be able to copy the entire contents of this web.config from an empty MVC3 application and paste it here. If you have modified this file and need to copy this section in, be sure to also copy in the configSections registration entries as well.

Next, in the Application Web.config file, add the following three appSettings entries (not required, but the new templates include these by default. See the MVC3 Beta release notes doc for more info on these entries):

Next, add these three new entries into the system.web/compilation/assemblies section:

Finally, add these two new entries into the system.web/pages/namespaces section:

 

4) LayoutPage –> Layout and _ViewStart

Another breaking change that was made from Preview 1 to Beta was the property used to assign a layout page to a view. In Preview 1, you assigned a layout page like this:

 

In the Beta, “LayoutPage” is now simply “Layout”

 

You also now have the option to define the Layout page for your site once, instead of in each view, by setting the layout in a page called _ViewStart.cshtml. Simply create this page in the root of your Views directory and add the following:

 

That’s it! You should now be up, running and back in business with MVC3!

Have you upgraded yet? If so, how was the experience for you? Leave a comment here if you had to make changes other than the ones I mention here.

Tagged with: • • •
 
If you enjoyed this article, please consider sharing it!
Reddit Facebook Twitter Delicious StumbleUpon Digg
  • http://www.gorangligorin.com/ Goran Gligorin

    I’ve been dealing with this upgrading just today. 1) and 2) didn’t affect me, but 3) and 4) did. I spent about an hour before I decided to make a new solution with the same name, copy the code over and just fix the Razor views.

    I tried the _ViewStart.cshtml thing, but it’s not the best. The problem is that it applies the Layout to all of the views. And that’s bad because unlike ASPX View Engine that has .aspx and .ascx files, Razor uses just the .cshtml, so the _ViewStart doesn’t differentiate between normal views and partial views. I hope MVC guys give us separate partial views file extensions. You can set Layout = null; but that kind of defeats the purpose of small clean partial views.

    But all in all I like Razor a lot more then ASPX. I’ve also installed the Razor Syntax Highlighter extension for VS2010 and it works great. I hope MVC 3 RTM comes out soon though. I really miss Intellisense in Razor views.

  • http://beatbilly.blogdrive.com/archive/1.html Jerald Mcglynn

    Handy, thanks a lot, book-marked.

  • Henning Kilset

    I’ve been attempting for a LOOOONG time today to get the StructureMap IDependencyResolver up and running, but have been unable to.

    It tries to instantiate Controllers through other means than through the container, even though I’ve set up DependencyResolver.SetResolver to use my new StructureMapDepencyResolver.

    (The controllers won’t instantiate and are complaining about default constructor lacking).

    Have you seen this?

  • http://www.userinexperience.com/ bsatrom

    @Goran, You can create a _ViewStart.cshtml per folder and override the settings of the main page, setting Layout = null in Shared, or in a seperate folder that just contains partial views.

    You are right though, no longer having different file extensions does introduce some new challenges for the team. :)

    @Henning, check out a sample here: http://bitbucket.org/bsatrom/razorlib/src/ in RazorLib.Infrastructure/Site. Does that gel with your implementation? Can you post your code as a sample on GitHub as a Gist? Maybe I can help.

    After you’ve set up your IDependencyResolver implementation, you still need to either implement an IControllerFactory or an IControllerActivator to actually perform runtime resolution of the controller from your container. Check out my sample above for both. I prefer the IControllerActivator, which is a new option in MVC3 beta.

Switch to our mobile site