Home > ASP.NET MVC > Updating from ASP.NET MVC Preview 2 to Preview 3

Updating from ASP.NET MVC Preview 2 to Preview 3

June 11, 2008

I have been using Preview 3 since it was recently released, but only in a couple of test projects and in conjunction with learning more about my new found love: jQuery. This morning, I thought I would undergo the task of updating one of my “real” projects from Preview 2 to Preview 3. Unfortunately, it wasn’t as straight-forward as I had hoped, so I wanted to share the process with you.

Updating References

First things first: my project is set to automatically copy the DLL references to the Bin directory, so even though Preview 3 is installed on my machine, pre-existing projects have no knowledge of it. This was confirmed by trying to use the new View method to call a view page. This is actually pretty obvious and was expected.

To correct it, I first had to remove the References to System.Web.Abstractions, System.Web.Mvc, and System.Web.Routing. Maybe it is available but I just don’t know about it, but I was sort of surprised that there is not an “Update Reference” feature in VS.

Then I had to add references to their new versions, found in the “C:\Program Files\Microsoft ASP.NET\ASP.NET MVC Preview 3\Assemblies” directory (default install location: YMMV).

Finally, to ensure there was still no confusion, outside of Visual Studio I navigated to the Bin directory and deleted the previously copied DLLs. This may not be necessary, as I expect the IDE to properly detect that a different version is now in play and copy the new version over the old. Since I am not so optimistic, however, I went ahead and deleted them manually. The next Build properly copied in the updated DLLs.

Correcting Compiler Errors

At this point, the Solution would not compile for two reasons. First, RenderView no longer exists since it was replaced with the simpler View method. I’m sure that if this had been a Beta or RC that they would have provided a new RenderView that simply wrapped the new View method and returned null. This would have preserved backwards compatibility, but hey, as good as this stuff is it is still just a Preview level technology, so I can’t complain. Besides, I ultimately agree with their decision because it would be silly to retain a method you don’t want available in the final Release.

Now, if you have a lot of RenderView calls and are Find-And-Replace averse, you can add a simple local method to your Controller class to do just what I was suggesting:

private void RenderView(string viewName)

I did not do this, but I don’t see why it wouldn’t work. And of course, if you are using any more complicated signatures you’ll have to replicate them as well.

Second, all of the ViewPages that use a custom ViewData type, you have to change all the property calls to now reference ViewData.Model.xxx. I just let the compiler direct me to where I had done so and updated them manually.

After making these changes, the solution compiled successfully.

Updating Web.Config

And now for the part that wasn’t as straight-forward. Web.Config contains “Add Assembly” tags that hard code references the assembly names and PublicKeyTokens for several assemblies, including System.Web.Abstractions and System.Web.Routing assemblies mentioned above. At run-time, the assemblies could not be loaded. I’m not sure why the refence replacement did not update these, but I believe the PublicKeyTokens had been changed. To correct them, I opened the Web.Config of a working Preview 3 project and copied those two lines.

Running the site again produced a separate instance of the same error, this time in the HttpModules section trying to add “UrlRoutingModel”, so I copied the appropriate line from the new Web.Config to the old one. I went ahead and went through the entire Web.Config looking for references to any of the three DLLs in question and found a couple more which I also replaced.

The Dreaded Blank Page Issue

At this point, the Solution compiled, but trying to run the site produced a blank page. Unsure as to the cause, I copied the entire Web.config file contents over (retaining my custom mods, of course), but to no avail. If I typed in the full URL of the default {controller}/{action} the page threw an error, but at least that was progress! It turns out in the Index.aspx I was using the ViewData.ContainsDataElement(“key”) method, which no longer exists. I changed this to ViewData.Keys.Contains(“key”) and the page would now load. When I tried it again from the root, however, I still received a blank page.

I remembered having a frustration right after switching to Preview 3 that no matter what Routing I added, the Default would always go to the Home controller. I found the answer at the ASP.NET MVC Forums: in Preview 3, the Default.aspx Code Behind includes a hard-coded Response.Redirect(“~/Home”) in the Page_Load method. I changed it to my default Controller name and everything began to function as expected. Remembering this experience led me to wonder if the problem was somehow related to Default.aspx, which would produce a blank page if successfully called. I have a Routing that is supposed to address this that worked fine in Preview 2, but apparently it no longer functions in Preview 3. Anyway, to make a long story shorter, I was going to add this to the Default.aspx Code Behind only to find that there was no Code Behind file in Preview 2.

Not being an ASP.NET developer, I’m not sure what to think of this, and I did not know any other way to handle the problem. I deleted the original Default.aspx file and added a new Web Form to my Project. I replaced the default Designer Code and the relevant Code Behind code to match my successful Preview 3 Default.aspx file, and I also updated the Response.Redirect line to point to my desired Controller. Finally, all seems to have been returned to normal.


While it was frustrating to work through, in hindsight it wasn’t all that bad. The changes are pretty easy to implement, once you know where the traps lie. And the moral of the story is simple: this is Preview technology, expect breaking changes.

Categories: ASP.NET MVC
  1. David Alpert
    June 12, 2008 at 3:02 pm

    If you are using MvcContrib, there are also a couple of breaking changes from the version that worked with Preview 2, including:

    – WindsorControllerFactory requires an instance of IWindsorContainer to be passed to its constructor so that it can be accessed from DisposeController.

  2. ahtesham
    June 27, 2008 at 6:27 am

    hey , i m new in MVC and i m using the latest preview 3.its really fustrating that all of the help and example on the net (exept the northwind example which is very simple) is in preview 2 and there is no help or example on preview 3 . my problem is that i want to know how we can replace all the server controls (like gridview and menu ) in mvc .
    and can u give me any example which is more then just links to other pages . also can u tell me what is diffrence between redirect and redirectToAction ,
    Also where is the documentation of MVC
    plz mail me back if any help

  3. June 27, 2008 at 9:47 am

    Hi ahtesham,

    1) You must realize that this is only preview technology: it isn’t even in official Beta status yet. And preview 3 was only released a short while ago: I’m sure once the technology is live that the documentation will be up to date. And there are some videos already available for Preview 3 on the http://www.asp.net/mvc/ web site, which I think is remarkable considering how recent it is and how quickly it is changing. Also, visiting the MVC forums at http://forums.asp.net/1146.aspx would probably help you a lot.

    2) You also must understand that this in not a replacement for Web Forms, so you won’t be able to simply drag and drop replacement controls. Instead, if you want to replace ASP.NET controls and functionality, you are going to have to hand code these components using traditional HTML, CSS, and JavaScript. Being able to use these core technologies is one of the most attractive features of MVC, but it is not for everyone.

    3) Redirect accepts a URL string and will redirect your requests traffic to the specified URL. RedirectToAction is used in to redirect the current request to another method (Action) within the current Controller or another Controller within the same Project.

    As for the rest, I think you need to spend some time at the website, forums, and on Google. There are plenty of samples and articles already available. Once the technology solidifies more, I will post some how-to articles. Until then, welcome to the bleeding edge!

  4. October 24, 2008 at 11:36 am

    Thank you so very very much. I struggled with the empty page for a long time.

  1. June 12, 2008 at 12:31 pm
  2. August 23, 2008 at 2:53 am
Comments are closed.
%d bloggers like this: