Rebuilding the ClarionMag archive site

As you probably already know, archive.clarionmag.com has been offline since the fall, when we transitioned to a new server that hosts both this site and the archive site. After an unsuccessful attempt to fix the problem, I resolved that it was time to bring that site up to date with current technology. 

The archive site was the official Clarion Magazine site until 2011; it's an ASP.NET MVC application that is actually the third generation of Clarion Magazine. The first generation was a mostly static site that got the mag up and running but was a nightmare to manage. I created the second generation site using Java, Tomcat and MySQL. I created the third generation site using an early release of ASP.NET MVC, the Sharp Architecture, and PostgreSQL. 

A lot has changed in recent years. And even though the ClarionMag archive site is an archive, it's also an important tool for managing subscriptions and mailing lists. It's long overdue for a facelift. 

But where to begin? 

The archive site is comprised of a number of Visual Studio solutions. There's one for the data layer, another for core non-UI functionality, yet another for core UI functionality, along with a smattering of unit test solutions. And there's one web solution that actually runs the web site. 

I started with the solution that had zero dependencies and worked my way up. But I had a few false starts.

I hadn't actually touched any of these solutions in about five years, and none compiled. Visual Studio couldn't even open the web application solution because it used some crazy build step that depended on obscure third party tooling that wasn't compatible with my current version of Visual Studio. 

Lesson One: If you have software out in the wild, you always need a way to build it, and the longer you defer that build the greater the potential pain. I no longer had a way to build working software. Either I should have kept a virtual machine around with VS 2008 and all the libraries, or I should have been maintaining the application all along the way. 

I had already decided I needed to upgrade the code, but if I had a working copy on hand it would definitely make the job easier. 

Anyway, no time for hand wringing. Onward!

I quickly learned Lesson Two: Libraries get outdated in a hurry. My application used a number of third party libraries that had undergone many changes, as had ASP.NET MVC itself. So I set about upgrading my libraries, but not without fear and trepidation. Supposedly .NET had done away with DLL hell, where incompatible versions of the same Windows DLLs cause varying degrees of grief. But my experience with .NET at the time was that DLL hell simply gave way to DLL version dependency hell, where I spent a lot of time figuring out which of my third party DLLs needed which other third party DLLs (which needed other third party DLLs, and so on) and hoping (often in vain) that I would not have to deal with different dependent versions. 

But in 2010, right about the time I was wrapping up work on the site, Microsoft released NuGet, an open source package manager for .NET development. NuGet takes pretty much all of the pain out of installing libraries and managing dependencies, and you can run the package manager right inside Visual Studio.

I got to work updating my packages using NuGet, and I quickly made the pleasant discovery that almost all of the tooling I had used previously was still available. I got to work with NuGet.

However in some cases I found that although the libraries were available, that meant being available for .NET 4.5/4.6 only, not for .NET 3.5 which is what I'd originally used. So I upgraded all of  my solutions to .NET 4.6. 

As you might expect, having upgraded libraries didn't necessarily mean my code all compiled. Some namespaces had changed, although in most cases a global search and replace took care of that. Some functionality was just plain different, which meant I had to find out how the code needed to be rewritten. And there were some real head scratchers, compiler warnings and errors that just didn't make any sense to me. Eventually I realized that I still had some of my old DLLs kicking around, so I deleted all the DLLs from the solutions, manually edited the .csproj files to remove all of the references, and tried again. A clean start did the trick. With a bit of elbow grease I eventually got all of my library solutions to compile.  

That left the web solution, which presented a much bigger problem. As I mentioned Visual Studio wouldn't even open that solution, and if it had I might not have liked the results because ASP.NET MVC has changed a bunch since I started using the better part of a decade ago. 

I decided instead to create a new web solution and begin grafting in my existing controllers and views. 

My views used a bunch of helper tooling and ASP.NET web forms syntax, with angle brackets and percent signs. But in MVC 3 Microsoft released Razor, a really slick view engine that makes views easier to read, write and maintain. In for a penny, in for a pound - it was time to start rewriting my views in Razor. 

That's where I'm at right now, trying to get the home page to display and to read the list of articles, news items and blog posts from the database. It looks like database access has changed a little from the early days, so although my data layer code compiles it won't exactly shock me if it doesn't work immediately. 

I'm enjoying spending some time with C# and Visual Studio again. Of course that has taken time away from producing Clarion content, although I think the effort will be worthwhile in the long run. And speaking of Clarion content....

Subscription changes coming

In the new year I'll be announcing a change to subscriptions and providing some information on the long term plan for Clarion Magazine (and yes, there most definitely is a long term plan). Stay tuned; I think think you'll be pleased.