Build errors with TeamCity, MSBuild, MVC Build Views and .Net 4.5

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.

Why does agile fail?

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.

Stop using Priority 1!

I will come as no surprise to hear that  I read a lot of blogs about agile and agile methodologies and  when it comes to ordering/prioritising the backlog you will usually have people talking about priorty 1 this, priority 1 that and with the stories being numbered in sequence e.g. 1,2,3,4, etc

To be honest I'm surprised that after all the years agile has been around that this is still what people are suggesting you do since its actually a complete pain to work with.

What am I talking about? Well if you have a backlog of say 30 items (I'm assuming they are in some sort of electronic system) and they are all number sequentially then if the business suddenly discovers something that must be "Priority 1" you have to alter every other story in the backlog to adjust their priorities and the work required to do this is really pure waste.

A better way of handling the priority is to invert the numbers, make the highest number the highest priority, this way if you want an new highest priority item you simply find the current top priority and add to its number, no need to reorganize the backlog, no change to what you have no waste, plus people often like the idea of giving a big number of a top priority so you are likely to get little resistance there.

An added bonus is with more numbers to "play with" you are less likely to get product owners/stakeholders trying to make everything "Priority 1" and more likely to engage in ordering the stories appropriately for the team to work on.

Also to make your life even easier don't number your stories using sequential numbers leave space between the numbers so that you can slot new stories in between existing ones if you need to.

So instead of 1,2,3,4 try using 4000, 3000, 2000, 1000 it will relive you of a little pain in your backlog management.