This post has been primarily delayed due to illness but also being very busy my new job.
Just like previous years I’m treating this as a retrospective on the previous year and planning for the year to come.
At the beginning of 2012 I set out the following headline goals I wanted to achieve:
Recently I moved an application from .Net 4.0 & MVC3 to .Net 4.5 & MVC4 which for the most part went fairly painlessly.
Previous to the .Net 4.5 upgrade the code was already being built and tested on TeamCity, but as part of the upgrade exercise it was decided to implement deployment from TeamCity using web deploy to a test server.
Getting web deploy set up on TeamCity is fairly painless and Troy Hunt has a nice set of posts about this, what it generally boils down to is using MSBuild to package the code and then calling web deploy to use the newly created package.
I set up the necessary build steps only to find that I was getting build failures on TeamCity when using the MSBuild runner (previously had used VS Solution runner) with the following error:
ASPNETCOMPILER error ASPRUNTIME: Could not load file or assembly 'System.Web.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
Project XYZ\XYZ.csproj failed.
Project XYZ.Tests\XYZ.Tests.csproj failed. Project ABC.sln failed.
I appeared to be able to solve this by adding an additional MSBuild property /p:VisualStudioVersion=11.0 which I found from this stack overflow answer.
Once done the code then built successfully but when it then attempted to package and deploy the web site it was failing with the error:
MvcBuildViews AspNetCompiler
AspNetCompiler C:\TeamCity\buildAgent\work\f2cfe4b9b1db787a\XYZ\obj\uat\csautoparameterize\original\web.config(27, 0): error ASPCONFIG: It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS.
I quickly discovered that this was an issue with the package command and happened because the obj folder wasn’t deleted, normally you get around this by altering the project file and telling it to use a different folder to output files to but this didn’t work for me.
After much searching I finally found the answer with this comment on a Phil Haack's blog post where I needed to add another MSBuild parameter /p:BaseIntermediateOutputPath=<your path here> which then allowed the TeamCity agent to create the package and successfully execute web deploy.
This took me a couple of days to resolve and the initial problem was that I had just upgraded to TeamCity 7.1 and incorrectly suspected it of causing me the problem, I was wrong.
Hopefully this post will help you if you too run into the problem.
There is more than one company out there that has tried to “go agile” but have ultimately failed and gone away with the impression that “agile just doesn’t work” or “agile’s great but just not for us”. You also have the situation where you have a company that has been working in an agile manner and then agile breaks down.
So why do people fail to successfully implement agile practices? what are the common reasons that are cited? who is to blame? In this post I’m going to cover some of the factors I’ve seen that can cause an agile adoption to fail, I’m not going to offer any suggestions on how to combat the various reasons but you could consider this a list of symptoms that could indicate problems if you want to implement agile in your organisation.
At the weekend I gave the a presentation “Inversion of control containers Vs HandRolled” showing the difference between using an Inversion of Control (IoC) container versus doing the dependency injection yourself.
I was asked a question on twitter Tuesday
“@philpursglove: @nathangloyn meant to chat with you at #ddd10 about why DI != IoC. Have you got a blog on this?”
There was a brief exchange on twitter about this but I wanted to just put my thoughts down around this.
For me Dependency Injection is a pattern, it is where a class that uses other classes i.e. is dependent on the classes, has these dependencies injected into it, whether this injection is via the constructor, property or methods.
When people talk about IoC they most commonly think of a container such as Ninject/StructureMap/Autofac, they think about it as a mechanism to handle the injection of the dependencies so they don’t have to worry about writing all the code to do this.
I believe IoC isn’t just the mechanism to implement DI but its exact definition is a little more difficult to pin down, if you read this wiki on the Castle project documentation then IoC is all about frameworks if you read Martin Fowlers article then its a principle to bear in mind when building your application. One thing that Martin Fowler does say in his 2005 article:
“There is some confusion these days over the meaning of inversion of control due to the rise of IoC containers; some people confuse the general principle here with the specific styles of inversion of control (such as dependency injection) that these containers use.”
He is describing DI as a specific style of IoC but I believe it simpler to think of DI as a separate pattern that can stand by itself but could easily fall under the general principle of IoC, hence DI != IoC.
Interestingly the closer you look at IoC to me it seems very similar to the Dependency Inversion Principle but that’s another conversation 
On Saturday I presented “Inversion of control containers Vs HandRolled” at DDD 10, I had a really good time and wanted to thank everybody that came to the session, this post is to provide links to the slides and code.
The slides can be found here although the font seems to have been altered so it doesn’t appear as it did in the presentation, I didn’t create the slides in comic sans honest!
At the beginning of the talk I said I didn’t intend to upload the code but I was talking to Rory Becker at the geek dinner and he convinced me to upload the code so that others could look at/play with the code, so you can find the code here.
As always any questions feel free to ping me 
Searching on Amazon for the phrase continuous integration (CI) you’ll get over 2000 results but looking at them you’ll find very few books actually on the subject.
This book has a unique slant in that it focus’ on the the .Net world and how you can introduce CI into your development practices and once implemented build upon that foundation to extend the functionality of your build server.
The authors have structured the book to take a CI novice from installing a CI server through to automating deployment or as Paul Stack describes in his talks how to climb the CI ladder.