Sorry for the late notice on this one (it sort of snuck up on me!)  I’ll be speaking at the North Houston .NET User Group (yes I said North, it’s new).  The talk is scheduled for Thursday, March 20th @ 6:30PM.  The meeting will be held at Montgomery College in The Woodlands.

I will talk about adopting agile development… the what, why, and how.  Hopefully it will be more of an interactive discussion, as there the audience can usually relate to the pain points that I talk about with traditional waterfall development.

For more details, check out their website.

Previously Scott Hanselman pointed out that in CodeCampServer we are using a tiny wrapper around MvcRouteHandler in order to catch all exceptions and provide the route information along with the error message.  I called this (for lack of a better name) BetterMvcRouteHandler.  That’s right, Better!

Scott took this a mile further and created a nice route debugging table that you can use while debugging.  You can download this route debugger on Phil’s blog (with source).

To enable the route table debugger, you have to add this line to your global.asax:

RouteDebug.RouteDebugger.DebugRoutes(RouteTable.Routes);

I think it would be better to be able to add ?routedebug to the end of ANY url and have this happen automatically.  To accomplish this I created an HttpModule.  It looks at each request for the ?routedebug querystring key and, if found, calls the line above.  I ran into a hiccup, though… once you set the route handler to the debug one, all future requests use it as well (even without the url parameter). 

Good ‘ol Phil released the source for this route debugger, so I added a method to revert the routes back to their original values if the query parameter doesn’t exist.

Here is the RouteDebugModule:

(remember:  this code would NOT be appropriate for production use, both for the awkward setting of route handlers on every request and the fact that you don’t want your users to be able to see your route information.)

And the RevertRouteHandlers method (in Phil’s RouteDebugger.cs):

The _oldRouteHandlers is just a static dictionary that hangs on to the route before swapping with the debug one.

I added the HttpModule to my web.config, and now I can do this:

…and also flip back to the regular request without recompiling.

I’m thinking they should call this BettererRouteHandler instead of RouteDebugHandler, who’s with me?

I said previously that I was excited for this release.  Ultimately I didn’t see much worth blogging about.  Some features are a step in the right direction, some (I think) were a step back.

I’m currently upgrade Code Camp Server to Preview 2 and hit about 80 errors which I had to go in and resolve.  My initial thoughts:

• I think the HttpContextBase is a bad idea.  Yes I understand the desire to not introduce breaking changes.  But I think that the people that will be using ASP.NET MVC will be congnizant of this and code appropriately.  Interfaces are much easier to depend work with while testing, and I’d rather just use those.  Hey, couldn’t they give us both, and framework providers could choose?
  
• what’s up with the OnActionExecuting, OnActionExecuted events?  These used to be OnPreAction, OnPostAction, which was much more readable (in my opinion) — seriously, put these back!  The new naming is not nearly as obvious to the glance.
  
• Testing is still too cumbersome.  I think some good mocking-fu can mitigate this, but it’s a tough sell to people new to unit testing (and to mocking).  TempData should be implemented as an IDictionary on the controller, only to have a real TempData that depends on session state at runtime.  This would allow me to test that TempData works without having to mock session (which is not intuitive at all).
  
• The Action filters are going to be where the goo lives.  This is how we will see some really productive & handy filters for performing actions such as requiring SSL, protecting an action from unauthenticated access, loading common data, etc.  Think of them as HttpModules for individual actions.

More to come, I’m sure…