Developing For .NET

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)
{
    View(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.

Conclusions

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.