London Calling

Ramblings of a software architect in London.


DotNetMigrations (DNM)

I’ve recently been trialling and contributing (work is still going on in a branch) on a small scale to a great little OSS project called DotNetMigrations. The GitHub site tells the full story, but essentially it allows you to write schema changes to your databases incrementally as you develop and automatically apply only the migrations you are missing if you are using an out-of-date database.

I’ve been working on making it very easy to integrate with existing projects by upgrading its NuGet installation. This is still a work in progress but the idea is that you can do the following:

1. Add DotNetMigrations to an application (web or windows/console etc.) using NuGet

2. A reference is added to DNM from your project, and the db.exe tool (that can be used to generate/run migrations standalone) is installed to your solution’s package folder

3. The required configuration (currently in appSettings keys) is added to the host application, this indicates the location of the migration scripts and the naming strategy

From that point on, as long as you sit in a command line that is inside the host application and reference the db.exe tool using a relative path, DNM will use your host application’s connectionStrings, completely integrating it.

For example you can then do commands like:

../../packages/DotNetMigrations-x.x.x/tools/db.exe generate "My first migration"

(to create a migration – you then open the generated file in any editor and add your schema change SQL)

../../packages/DotNetMigrations-x.x.x/tools/db.exe migrate myconnectionstringname

(to update the database pointed to by the connection string myconnectionstringname to the latest migration level)

Some future possibilities:

  • Including these calls as Powershell commands so that they can be run from within the NuGet Package Console, and to avoid having to use a separate command line and use awkward relative paths
  • Adding “auto migrate” logic to an application’s start-up code (optional) that will host the DNM core and upgrade databases on start-up to the required level
  • Along the same lines, should we be allowing people to package migrations as application resources?

Any thoughts or suggestions?

Using VS.NET web application projects with both VS.NET 2008 and 2010 RTM

What a palaver. Prior to RTM you could use VS.NET 2008 and 2010 web application projects alongside each other with no issues (after having 2010 upgrade them). With RTM, you get horrible issues with the line:

<Import Project="$(MSBuildExtensionsPath32)MicrosoftVisualStudio
    v10.0WebApplicationsMicrosoft.WebApplication.targets" />

Added to the bottom of your .csproj files. After much soul searching I’ve found a solution with a bit of MSBuild cleverness. Turns out you can conditioanlly include MSBuild targets depending on the version of Visual Studio being used.

So, for each web application project in your solution:

  1. a) Have VS.NET 2010 upgrade your projects to the newer version.
  2. b) Replace the above line with:
<Import Project="$(MSBuildExtensionsPath32)MicrosoftVisualStudio
    Condition="'$(Solutions.VSVersion)' == '9.0'" /> <Import Project="$(MSBuildExtensionsPath32)MicrosoftVisualStudio     v10.0WebApplicationsMicrosoft.WebApplication.targets"
    Condition="'$(Solutions.VSVersion)' == '10.0'" />
  1. c) Blank out <FileUpgradeFlags></FileUpgradeFlags> which VS.NET 2010 has probably put “4.0” in, this will trip 2008 up otherwise.
  2. d) Blank out <UpgradeBackupLocation></UpgradeBackupLocation> in the same manner.

As long as you can then live with working with a seperate solution file for VS.NET 2010, you should be away and can stop annoying anyone else working on your files!

.NET Settings Providers

I’m researching different methods of persisting, updating and managing configuration in .NET, as I’ve become a bit tired of rolling my own static “Config” class.

Having used the newer Settings architecture (as opposed to the old fashioned non-typed AppSettings) on a small scale site, I’ve been interested in how it might be possible to extend these over a distributed system.

Turns out you can, the system is pluggable.

Over the next few weeks I’ll be exploring how this might benefit an application – especially in the area of not having to restart when writing to app.config files!

Sending E-Mails (the longer than usual story)

Very interesting article (fewer and farther between unfortunately these days) from Jeff Atwood about some of their experiences with building Stack Overflow and sending out mails and having them actually arrive! Quite pertinent as I’m currently working in a similar area.

Essentially, firstly send mail from your client to: and get a free report on basically what you’re missing from your setup. You can do this over and over again to get a picture for how you’re progressing.

Obviously the article goes into detail, but in summary:

1. Make sure the computer sending the email has a Reverse PTR record

2. Configure DomainKeys Identified Mail in your DNS and code

3. Set up a SenderID record in your DNS

Basically they are all a combination of adding the correct TXT and PTR records to your domain names, as well as generating a public/private key pair, signing your mails with the private one and making the public part available via DNS.

They use a commercial piece of software called Mailbee.NET to do the signing work, but this is possible using good old SmtpClient with something like this:

Not production code by any stretch of the imagination, and some of the work he does to build a CN and do the actual signing could be done using the built-in BCL classes but you get the picture. I’ll post again when I have this working.

ASP.NET MVC vs. Ruby on Rails

Quite an interesting article on this, if extremely biased towards RoR.

A few salient points:

  • RoR is entirely command line based, ASP MVC is obviously more tied to Visual Studio (although I would debate that as you could do everything by command line, ms build and notepad)
  • Very similar in all basic respects.
  • No analysis of more important and “edgy” factors such as model binding (ASP MVC is very good at this) and validation frameworks.
  • I’m still jealous in some respects of RoR DB migrations – I wonder if there is a .NET based port of this going anywhere? I should lend a hand if so.
  • Routing is a tie, both good.
  • Pretty much parity beyond that (at least as far as the article is concerned).


I’m trying to come up with a standard and reliable way to trigger a core dump from within the logging/exception handling of a C# executable. The above article indicates that this should be possible, but it sounds as if making this work across platforms would be a fairly large nightmare.

If anyone has done anything similar to this, I’d be interested to see how you went about it, and if possible maybe we could share/release some code to make this easier.

Genius at Work

Here’s a Channel 9 interview with Anders Hejlsberg, the creator and head designer of C# as a language (as well as Delphi back in the day).

Interesting in that it examines some of the improvements in C# 4.0, as well as features that are being bandied around for even further out.

Also contains the best description of contra-variance and co-variance that I’ve seen so far.

AnthemNxt HttpModule and other fun and games

I’ve spent most of today doing some more work on AnthemNxt to continue simplifying the code base and making the framework even more fool proof to work with.

  1. Separated out the single project into AnthemNxt.Core and AnthemNxt.Controls. For now development will concentrate on Core and further simplifying that. Any patches for Controls will be happily received however as I know many people have their own Anthem controls kicking about.
  2. Created a dedicated AnthemNxt.Tests web application project which I’ll repopulate with the old Anthem tests at some point, but for now I am using as the basis of my tests for a HttpModule that will simplify Anthem error handling.
  3. Separated script management out of AnthemNxt.Core.Manager into AnthemNxt.Core.ScriptManager with the intention of eventually allowing the use of this ScriptManager in place of the built in ASP.NET one no matter if you are in a callback or not.
  4. Created AnthemSection (configuration section handler for web.config) from where the old settings are now read and where any new settings will be placed.
  5. Created AnthemModule (which is now required to be included in web.config and will be reported as missing if so) which will be used to pave over the slightly manual way in which Anthem used to handle reporting errors back to the browser. The intention is that Application_Error will work identically as it does for postbacks to give you the chance to log information etc, yet redirects to error pages etc from within there will still be honoured using the callback scheme.

I’ve also added two controls of my own:

  • AdvancedValidationSummary (encompasses all the functionality of ValidationSummary but also allows you to place a control that will catch errors for all validation groups that do not have their own summary control)
  • CustomValidator (allows code behind to simply set some text to indicate an error, ideal for logic errors where simple validators are not complex enough).Enough for tonight! Code is committed and builds correctly. :)
  • Error Handling and Exception Logging

    I’ve been struggling with Anthem.NET for some time to work exactly how I would like (and expect) as regards to the event flow for an unhandled page exception.

    In the original 1.5.1 release of Anthem, the Application_Error event was bypassed by a hook added in Manager.OnError as follows:

       1: private void OnError(object source, EventArgs e)
       2: {
       3:     if (IsCallBack)
       4:     {
       5:         _error = HttpContext.Current.Error.ToString();
       6:         HttpContext.Current.ClearError();
       7:         WriteResult(HttpContext.Current.Response, null, _error);
       8:     }
       9: }

    Which meant that any global logging (we use log4net) of an error that you do in Application_Error does not fire and so you end up with the unsatisfactory situation where errors in callbacks occur silently to your operations team whilst returning correct information back to the JS client portion of Anthem.

    This can be worked around by writing a JS Anthem error handler that then calls an AJAX method which triggers a log of a message, but that is convoluted, inefficient and unrelhable and not an acceptable solution for me.

    In the latest source of AnthemNxt I’ve removed the above OnError handler and let the exception proceed as a normal postback would (so my Application_Error handler DOES get hit now and I get exceptions fully logged).

    However now there is a HTML error page returned to the JS client and not a valid JSON response because the OnUnload Anthem handler is never called (since the page rendering is hijacked due to the exception). Until I can write a HttpModule to overcome this and make AnthemNxt a true drop-in library, I’ve broken out the OnUnload AnthemNxt functionality so that it can be called from Application_Error:

       1: private void OnUnload(object sender, EventArgs e)
       2: {
       3:     CompleteRequest();
       4: }
       6: public void CompleteRequest()
       7: {
       8:     var res = HttpContext.Current.Response;
      10:     // Handles inserting JS to do a redirect 
      11:     if(Manager.IsCallBack && res.StatusCode == 302)
      12:     {
      13:         string href = res.RedirectLocation.Replace("", "\").Replace("'", "'"); 
      14:         res.RedirectLocation = string.Empty;
      15:         res.Clear();
      16:         res.StatusCode = 200;
      18:         var sb = new StringBuilder();
      19:         Manager.AddScriptForClientSideEval("window.location='" + href + "';");
      20:         JsonWriter.WriteValueAndError(sb, null, null, null, null, null, null, null, clientSideEvalScripts);
      21:         res.Write(sb.ToString());
      22:         res.End();
      23:     }
      24: }

    as so:

       1: protected void Application_Error(object sender, EventArgs e)
       2: {
       3:     log.Error(ex.Message, ex);
       5:     // If we are in debug mode get the usual "yellow screen of death" up, makes debugging easier during development 
       6:     if(!Manager.IsCallBack && HttpContext.Current.IsDebuggingEnabled) return;
       8:     // Redirects to an error page - need to not end the request if this is a callback
       9:     // so that AnthemNxt can write a JS redirect into the JSON response
      10:     Response.Redirect(“~/error.aspx”, !Manager.IsCallBack);
      11:     if(Manager.IsCallBack) Manager.Current.CompleteRequest();
      12: }

    Hopefully with a HttpModule I can make this fully automatic, but for our purposes this is better than the existing behaviour for now :)

    Anyone interested in contributing, whether it be patches, comments or just bugs please get in touch or use the Codeplex project.