Looking for work

I'm looking for work and open to offers.
You can email me on 'jobs at nigelthorne.com'

Keeping Dynamically Loaded Plugin Assemblies unlocked in ASP.Net

I have written a plugin system for an asp.net application. The system basically searches a plugin directory for assemblies containing types implementing the IPlugin interface. To do this it needs to load the assemblies at runtime. The problem I had with this was that it locked the files once they were loaded. If I then compiled a new version it failed to copy the assembly to the desired location as the file there was locked by the asp.net worker process. I tried various solution to do with creating my own appdomain. I didn't get much success with these. You will have to do this if you want to unload your assemblies at any point though, as AppDomain.Unload unloads the whole domain.

Anyway... it turned out that the best solution for me was to get asp.net to shadow copy the assembly for me. This was as simple as putting the following code in your ApplicationStart in Global.aspx.cs


AppDomain.CurrentDomain.SetShadowCopyPath(
AppDomain.CurrentDomain.SetupInformation.ShadowCopyDirectories
+ ";" + Server.MapPath("~\plugins"));


For further information look here, here and here.

Feed link changed

please update your atom/rss links to : http://feeds.feedburner.com/nigelthorne/blog

Another Rails Conf Talk Released

I'm loving ScribleStudio's coverage of the RailsConf2006 Keynotes.

One of the questions to the Rails core team was 'do you guys hate fixtures?' or something like that. I was amazed that they too dislike them. DHH summed it up well... to paraphrase.. Fixtures shouldn't be shared across tests, but they are so hard to set up that you end up doing it anyway, which doesn't scale. The cost of making fixtures needs to be lowered. They didn't have any ideas how to do this.

This make me recall my suggestion from a few days ago... instead of fixtures, define an object mother (some class that can generate test data for you given some criteria) and dependency injection or some other terse mechanism to specify your context for your test.

Looking at the way rSpec is going, this maybe the best condender for this sort of thing. I'll keep thinking about it. Keep tuned to see any further developments.

... and as always feel free to leave comments

DSLs in Ruby

There are two approaches to writing DLSs, Internal and External to the implementation language.

With internal DSLs the ruby parser is used (eg. ActiveRecord). It is surprising just how much you can personalise your language and still remain within the syntax of ruby.

see 'Creating DLSs In Ruby'

External languages require you to write a parser. This sounds hard, but there are a few libraries available that simplify the process. Check out multi and sexp gems.

see 'If It's Not Nailed Down, Steal It'