Developing For .NET

Yesterday I wrote about updating to ASP.NET MVC Preview 5. Today I tested the changes I made and they failed, so I obviously had a little more work to do.

First, I had to update the Web.config file in several places (just like I did going from Preview 2 to Preview 3.) The only way I could get this to work was to create a brand new Preview 5 web page project and copy the afflicted lines from the new Web.config to the old one. I also went ahead and updated the namespaces, httpModules, and httpHandlers sections.

Then, with the site actually running again, I tried a full blown walk through and discovered a problem. Since System.Web.Mvc.BindingHelperExtensions was replaced with a call to UpdateModel(model, Request.Form.AllKeys), an error occurred. Specifically, a NullReferenceException was thrown because “AllKeys” contained form elements that are not properties in the model object. My gut reaction was to simply add them to my class, but that just didn’t seem right: the model should be unaffected the presentation.

So, at least as a temporary solution, I created a custom List<string> of Keys. I used Reflection to get a list of Property names, and if those names are in Requst.Form.AllKeys then I add it to my list:

typeof(TransactionRequestInfo).GetProperties().ToList().ForEach(p =>
    {
        if (Request.Form.AllKeys.Contains(p.Name))
        {
            keys.Add(p.Name);
        }
    });

UpdateModel(pmtInfo, keys.ToArray());

{NOTE: TransactionRequestInfo and pmtInfo are from the Authorize.Net project, which I still need to update on the site.}

After I got it working, I realized that this is actually a query, so I could use Linq instead:

var keys = from p in typeof(TransactionRequestInfo).GetProperties()
           where Request.Form.AllKeys.Contains(p.Name)
           select p.Name;
UpdateModel(pmtInfo, keys.ToArray());

This shortened the code, got rid of a Lambda Expression, and prevented the need to cast the Properties[] to a List<PropertyInfo> object.

I should probably add logic to make sure only Public properties are selected. Since I may end up using this in more than one place, I will probably want to make it an Extension method of Request.Form.

One more problem

After updating my assembly references in Web.config and reloading the site, I received an error because it could no longer find the referenced assembly.  I checked in my bin folder and sure enough the assemblies were not there.  Compiling the solution did not replace them as it had before, so I copied them into bin from the C:\Program Files\Microsoft ASP.NET\ASP.NET MVC CodePlex Preview 5 directory and reloaded the site.  Once again, all is working properly.

Well, I once again fell off the wagon when it comes to updating this site. I’ve been so busy working on my new ASP.NET MVC project that I even missed the Preview 4 update. That would be bad enough, until I recently found out that Preview 5 is now out. What a slacker I am!

So I spent the last little bit updating my Preview 3 projects to Preview 5. I don’t know how much of this was Preview 4 specific since I skipped it entirely. Here is what I did:

1. Uninstall Preview 3 from my PC.
2. Close all Visual Studio instances.
3. Install Preview 5.
4. Open my MVC projects.
5. Remove previous references to System.Web.Abstractions, System.Web.Mvc, and System.Web.Routing.
6. Add these references back, pointing now to the new install path.
7. Add a reference to Microsoft.Web.Mvc, found in the same location.

Breaking Changes

I had used System.Web.Mvc.BindingHelperExtensions in several locations, but this functionality has been moved to the Controller class. To correct it, simply replace the calls to BindingHelperExtensions.UpdateFrom(model, Request.Form) with UpdateModel(model, Request.Form.AllKeys).

That was all I had to do to get it up and running. Now I need to uninstall Preview 3 from the server, install Preview 5, and reload my sites.

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.

Last week, I finally got the ball rolling on our IIS server. With a little help from a friend, I managed to get the SSL Certificate installed. A quick tutorial, and the site was moved to the server but it would not respond. Monday, I managed to get the site to respond by installing the .NET 3.5 framework on the server and I mistakenly thought it was up and running, so I released it to the beta testers. Of course, immediately the testers informed me that only the home page was showing, while all other links returned a 404 message.

I went through several efforts and can now happily say that it does work, so I am officially saying it is deployed. It is far from finished, but it is live on the web (sorry, I can’t share the address at this time). Here are the steps I followed that got it running:

1. Install .Net Framework 3.5 on IIS Server
2. Change Route URLs in Global.aspx.cs to include the .mvc extension (this is in the comments for that file)
3. Install ASP.NET MVC Preview 2 on the IIS Server.
4. Add an ISAPI extension to the application for .mvc that points to “c:\windows\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll”.
5. Uncheck the “Verify that file exists” box on the Extensions configuration dialog.

The last one is what finally made all the pieces fall into place. I don’t know if it is a “DUH” sort of a thing, but you have to remember that I am not an IIS or ASP.NET guy.

I found information on all but the last entry scattered across the web. Hopefully by putting them all in one place it will help some poor wayward soul in the future. According to those resources, these steps should also work for IIS7 in classic mode (integration mode? are those the same?) but should be unnecessary in the default IIS7 configuration.

At any rate, it lives!

ScottGu has just announced the release of the ASP.NET MVC Source Code. You can download the code from CodePlex. It is important to note that this does not mean MVC will be open source (or that it won’t be), just that they are sharing the code during development so that we do not need to wait for their releases to correct bugs locally. So while you can create a custom implementation, you cannot distribute it, and I wouldn’t want to rely on it.

Last Updated 03/12/2008

This morning I watched a video from Mix08 of Scott Hanselman’s session on ASP.NET MVC. I enjoyed the presentation, although I’m sure I will have to watch it several more times. The Routing capabilities are phenomenal but they will take a little while to get my head around. For now, the default Routing mechanism should suit my purposes just fine. I can also see that I am going to have to learn about Unit Testing, so that (in Scott’s own words), I don’t “suck”.

I have been developing a site using the new MVC approach, and overall I ahve to say I finally feel right at home in ASP.NET. I still get all the C# and Framework goodness I am used to, but I can now do it in the close-to-the-HTML way that I am familiar with. Let’s face it, until ASP.NET, WordPad was my web IDE of choice.

In the video, Scott asks us to blog and post about what we would like to see done differently in MVC, so that is the purpose of this post. I will use it as a running tally of my MVC Wish List. My first item was addressed in Scott’s presentation: I wanted the ability to route all non-conforming traffic to a default page rather than relying on the web server configuration and 404 files, and all that ugliness. Well, apparently you can already do this by declaring a *catchall Route. When I figure out the mechanics of this I will try to post a sample.

The Wish List:

1. Make UrlHelper.Action() Static

Make appropriate UrlHelper methods (and probably also HtmlHelper) available in a static context. I wanted to add standard navigation to my page in my custom MasterPage, but I could not use the Url.Action( action, controller) method because at that point there is no ViewPage instantiated. I think this would provide a uniform approach to Url writing.

2. Supply a pre-action Controller Event – added 3/11/2008

I think it would be great to have a generic event (or maybe a partial method?) that would execute before the controller begins the action method. This behavior could be simulated now, but each action would need to explicitly call the method. Implementing it this way would ensure that it was executed every time the controller was called. I think this could be great for things like caching, session management, security, logging, etc.

Update: Scott commented below about a possible solution to this already in place. I don’t think it is exactly what I had in mind, but I will experiment with it when I can and report back.

3. Add a TableRow method to HtmlHelper – added 3/12/2008

I’ve been playing with Html.Form<T> and BindingHelperExtensions.UpdateFrom for building and processing form elements. I think both of these are very cool, and I will be posting about them shortly. Since Form elements are frequently presented in a Table, it would be good to have something like Html.TableRow<T>(inputType, label, T.Property) [obviously this is psuedo-code] that would create a simple table row based on the property with two elements:

<tr>
  <td>label</td>
  <td><input type="text" name="Property.Name"
    value="Property.Value"></td>
</tr>

The main benefit of this would be automatically generating the correct property name, so that it lined up perfectly with the UpdateFrom functionality. Another benefit would be to have it automatically populate the Value attribute with the current value of the Property. InputType above would ideally be able to accept the results of Form.Select, Form.Textbox, etc., or could be overloaded with an enum and some additional parameters.

OK, so that is the short (and boring) list for now. As I get further into the project, I’m sure I will find more, but as of now I have a lot more to rave about than to complain about. Keep up the great work fellas!