So it appears I have not made a post in a while.  It has occurred to me that I update the site constantly but I have not posted anything in some time.

What do I mean I update the site constantly?  Every developer should have a project to tinker with and try to expand their skill set.  In my case I have written my own blog engine and maintain it.  As I find new features –like the search—that I want to add I spend the time to define the scope, requirements and use cases.  I write and test the code before deploying it to my web host.

But I do not post about it.  I do not write anything about what I have discovered or learned and I certainly do not discuss how easy or difficult the patterns I have used/tired are to maintain.  I have rewritten the site a few times over the years from the ground up.  I have switched from web forms to MVC web forms to MVC with the Spark view engine and to  MVC3 with Razor.  But I have written very little about most of those rewrites.

This got me to thinking that I really should post about what I am doing, what I have done, and why. 

On that note I am starting a new series, Site Update.  While it is not terribly exciting It will give me a chance to talk about what changed, when, how and why.

What is fixed

This update fixes a couple things that have been broken for a while now.  First, a long long time ago on a host far far away… I had a “.com” domain name for  I have long since let that domain name die.  This caused a  few links within some older posts to break and bounce to some marketing groups site who picked up the old domain name.   I added a database migration to run a search and replace on the post body and excerpt for the old domain name and replace it with if you are wondering there were 19 instances  of the .com domain replaced by the migration.

The second issue I addressed stemmed from changing blog engines a long time ago.  Originally, I used the  dot net blog engine.  It was a wonderful engine and it had more features than I could shake a stick at.  The post URLs left a little to be desired at the time. When I wrote my new engine I included a URL redirector for SEO reasons.  So the old post URL of would issue the proper permanent redirect to  I did not realize that I  had overlooked some of the old style URLs to the older articles while others were corrected.  Recently, while refactoring the blog controller I may have broken the SEO redirector.  The short of it was I changed a route and it was an odd case that my unit tests did not take into account.  That means that some  links were not routing to the correct page within the site. As of this post there were 23 SEO redirects for the older posts that were failing because of the route change. 

So I fixed both of these issues.

Nothing terribly exciting but it has given me pause to consider…  Do I need to unit test my routes and what is the best way to go about unit testing routes?  I am currently using mstest for unit tests but I am considering setting up a CruiseControl.NET server in my house. I have tried, unsuccessfully, in the past to get to run mstest.exe without a full install of Visual Studio.  I believe there maybe some licensing issues trying to run mstest.exe without a licensed copy of Visual Studio installed on the build server; there are enough file and registry reference issues to be a pain.  So maybe  I need to switch to nunit and rewrite/convert my tests and add route map tests.

Perhaps that is my next project.

DotNetKicks Image