Our favourite piece of code seen recently is from a while ago: Building an IoC container in 15 lines of code. We like it because the intent is really very clear. Every now and then we find some use of Spring.NET or mention of IoC. Sometimes wonder whether it's necessary or being used because Developer-X wants to indicate sophistication. So then as a refresher we often end up here: Inversion of Control Containers and the Dependency Injection pattern. Written 35 Internet Years ago.

Looking at the way applications are written circa 2008 it appears IoC is reasonably common and therefore time to incorporate. Known advantages:

• Decoupling
• Service Orientation (is this repetition of the first?)
• Testability
  • Allows mocking

The fact that we've neither been tripped up by object graphs nor troubled with dependency suggests not having done anything nearly enterprise enough. That, rather than an eidetic view of object relationships. Still, there's an argument for trying to incorporate a different approach into the ordinary as a means for seeing the ordinary for being less than splendid.

Right, so which one do we go for?

• Windsor (Castle Project MicroKernal)
• StructureMap
• Autofac

The nice thing about Autofac is that it's capable of using a delegate or Lambda Expression rather than reflection for component creation. As stated elsewhere, .NET 3.0 style. We like.

Notes:

Useful to make explicit the difference between Inversion of Control and Dependency Injection. Hint: The latter is a specific form of the former. Nice one, Wikipedia!

Back in 2002 we were trying to learn C# - having felt like we'd conquered VB.NET in 2001 - there was a *thrilling* chance to learn about the .NET programming model by developing creatures and introducing them into a peer-to-peer ecosystem... Terrarium! Welcome home disposable heroes.

I think we spent a week trying to get the friggin' thing to work before someone let us know that it had nothing to do with our ineptitude and everything to do with our beta version of Visual Studio. Cue decision to wait until technology beds down before adoption. Much cooler to be an Early Adopter but it required a level of patience beyond us; we watched and laughed as early versions spat out their problems. Widely anticipated, widely hyped technology seemed to disappear. Late adoption served us well. Looking down Memory Lane:

• Object Spaces
• InfoPath
• Tablet
• Etcetera

That was then. WxF looks to have good momentum - read: it's showing up on job specs - so cue once more frustration of technology adoption prior to it becoming mainstream. Pair of Snake Eyes.

First take involved opening solution in Visual Studio 2008 and publishing to localhost and then using FTP to send files individually whereupon we discover that using O2 mobile broadband (via USB) results in files arriving "successfully" on remote web server with file size 0KB. Yuck! Many more takes to replace "successfully" transfered files. Don't blame FileZilla because it's doing only as it advertises and we've had issues with FTP ourselves quite recently from within code we'd written.

Digression: It was necessary to compare file content between local and remote files before assuming successful transfer. Not pretty. Never discovered a better solution that didn't involve MoveIt.

Finally everything copied across and directory turned into Web Application using the DiscountAsp.Net unsurprisingly named Web Application Tool. Instead of blog appearance we have this compilation error!

So it turned out there are at least two ways of resolving this without trying to understand intricacies of ASP.NET Dynamic Compilation and being frustrated by not being able to delete Temporary ASP.NET files on a remote server which denies access to said directories and probably with good reason. Wondering why WebDAV isn't an option here though... probably a good reason I'm not aware of.

• Twenty One step program on How to Convert BlogEngine.NET Web Site to Web Application Project; or
• Follow these instructions on How to Install BlogEngine.NET (which I reckon counts as a single step)

If you see this then everything's turned out okay. Global warming has been corrected. If you care in even the slightest this application defaults to using an XML file datastore and so we need to weigh up whether there's any advantage to pushing this into SQL Server. Climb the mountain because it's there? Okay, it's probably not quite a mountain and we'd not do it in a tutu.

Notes:

MSDN: Understanding ASP.NET Dynamic Compilation

Post Script:

It's a love/hate relationship with Infrastructure.

• By their being responsible for deployment I'm sometimes spared the headache of failed deployment.
  • In this first instance someone else discovers/solves the problem.

• By their being responsible for deployment I'm sometimes victim of failed deployment.
  • In the second instance someone else *is* the source of the problem.

Poetry very incidental.