adamjcooper.com/blog

Enterprise Software Development in C#


Migrating to ASP.NET MVC Beta from Preview 5

Congratulations to the ASP.NET MVC team, the first official Beta is out. You can download it here.

ScottGu offers an excellent guide to what has changed, and Scott Hanselman and Phil Haack also announce the Beta and summarize what's new. I'll let you read their blogs to get the new features list. I'm going to use this post to outline what I had to do in order to get my existing Preview 5 project converted over to MVC Beta.

Installation

You will need to uninstall Preview 5 (or any other Preview) before you can install the new version.

Update Your References

If you have any projects that are currently depending on the Preview 5 assemblies, you will need to remove the references to these assemblies and then add references to the new assemblies. Specifically, you need to update:

  • System.Web.Abstractions.dll
  • System.Web.Mvc.dll
  • System.Web.Routing.dll

The new assemblies are typically located in C:\Program Files\Microsoft ASP.NET\ASP.NET MVC Beta.

The installer apparently also places these assemblies in the GAC, but I don't recommend using them this way. First, the .NET tab of the Add References dialog is mysteriously missing System.Web.Mvc (though it contains .Abstractions and .Routing). But more importantly, if you want to deploy to your web server without having to change anything on the server itself, you should add local references for these three assemblies.

Use Local Copies of the MVC Assemblies for Easy Deployment (Avoid the GAC)

I had an issue with my application running fine on my local machine but not on the web server that turned out to be a GAC/local bin conflict. I had added references to the MVC assemblies by browsing to C:\Program Files\Microsoft ASP.NET\ASP.NET MVC Beta, like so:

image 

However, each of these references had "Copy Local" set to False, and my web.config file contained assembly references in the compilation section that referenced the GAC. So, when I ran on my local machine, the GAC assemblies were present and it worked fine. But when I pushed out to the server, the MVC assemblies were not included in the local bin folder, and since the MVC Beta installer hadn't been run on the web server, it obviously didn't work.

The solution is to make sure that the MVC assemblies have Copy Local set to True, which ensures that you get a copy of the assembly in the local bin folder:

image

And you can remove any lines in your web.config that reference the GAC versions:

image

If I'm misrepresenting something here someone let me know.

Futures Assembly (Microsoft.Web.Mvc.dll)

If you have any references to the ASP.NET MVC Futures assembly (Microsoft.Web.Mvc.dll), it will also need to be updated. However, now that MVC has entered Beta status, the Futures assembly is no longer being included in the installer. You will need to download the updated Microsoft.Web.Mvc.dll, updated for MVC Beta, from CodePlex.

Rebuild Your Projects and Correct and Breaking Changes

If you're lucky, all you'll need to do is update your references, rebuild, and you're done. If you're like me, you'll hit a few snags along the way and need to make some changes to your code.

Gotchas

Here's what got me when I updated to MVC Beta:

ActionLink Bug?

I tried using one of the new ActionLink overloads, specifically ActionLink(string linkText, string actionName, string controllerName, object values) but I could never get it to produce a link with a correct href. Instead of a valid URL, I'd get a URL that had a ?Length=n tacked onto the end of it, where n was the length of the controllerName string. Very strange, and very frustrating. Has anyone else noticed this?

Strongly-typed Html.ActionLink moved to the Futures Assembly

The strongly-typed version of ActionLink is now in the ASP.NET MVC Futures assembly (Microsoft.Web.Mvc). If you want it back, you'll need to download the new Beta-compatible Futures assembly from CodePlex and add it to your project.

ViewContext.ViewName Removed

I'm not sure why. In the meantime, you can use the much uglier ViewContext.RouteData.Values["action"].ToString(). But I'd sure like to see that property come back (or at least get a good explanation of why it disappeared).

AddModelError Changes

If you were using the ViewData.ModelState.AddModelError method, you'll notice the second parameter, attemptedValue, is gone. That's because the there's a new, independent SetAttemptedValue method you should use instead. This makes sense--you may need to set multiple errors for a single attempted value, so the two operations should be teased apart.

Html.Form is now Html.BeginForm

If you're looking for the Html.Form helper method, it's now named Html.BeginForm. Scott Guthrie elaborates.

MvcContrib.Ninject

I'm currently using Ninject in combination with NHibernate. With Preview 5 I was using the Ninject support offered in MvcContrib, but this doesn't work with MVC Beta. The good news is that the latest version of Ninject comes with its own, more streamlined support for ASP.NET MVC, and it works fine with the Beta version. I may blog more about the details in a future post, but the short story is this: You need to checkout the latest version of the Ninject source code (svn checkout http://ninject.googlecode.com/svn/trunk/ ninject-trunk), add references to Ninject.Core.dll, Ninject.Conditions.dll, and Ninject.Framework.Mvc.dll to your MVC project, and then update your Global.asax file as outlined in Emad Ibrahim's blog: http://www.emadibrahim.com/2008/08/21/ninject-killer-ioc/.

Be the first to rate this post

  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Comments

Add comment


(Will show your Gravatar icon)  

  Country flag

biuquote
  • Comment
  • Preview
Loading





 
Powered by BlogEngine.NET 1.4.5.0 | Design by adamjcooper