The Day 4.5 Broke Our Build

If your organization is like most (including mine) you don't rush out and get the latest and greatest tools the day they come out.  In fact, I can't think of anyone who does that.  We wait until there's either a) a budget surplus (yeah, because that happens in real life) or b) a need to upgrade.  That's how we found out that .NET 4.5 can break your build... even when you're programming .NET 4.0.  Allow me to explain.

We started our application rewrite (check out TDWTF for a funny explanation of the perfect scam) a couple years ago using MVC3 and .NET 4.0.  Of course we had to upgrade to Visual Studio 2010 to do this, so we did.  The rewrite got underway and a short way into it, Visual Studio 2012, .NET 4.5, MVC 4 and TFS 2012 all came out and we collectively decided we couldn't live without all of these things.  We all got VS 2012, we upgraded the TFS server to use TFS 2012, and we started on our merry way.  We decided to delay upgrading our target framework to 4.5 and also to delay upgrading our project to an MVC 4 project, but at least we were using 2012!

Then we used TFS to build and deploy our code to our dev server for the first time.  No sweat, right?  We right-clicked and hocus-pocused and voila! the site crashed... So what happened?  Well, this was the Day 4.5 Broke Our Build, remember?  So, obviously, 4.5 broke our build.  The end.

Or not.  In case you don't know, .NET 4.5 overlays .NET 4.0 so when you install 4.5 you "lose" 4.0.  That means that even if your code targets 4.0 the build server will build everything using 4.5, if 4.5 is installed on the build server.  So the build server builds your project using the 4.5 assemblies instead of the 4.0 assemblies and pushes your final code to the deployed server so it can actually be used.  Well, if the deployed server doesn't have 4.5 installed on it... BOOM!  This is where you start to get the MissingMethodException.  Ours was something along the lines of "Environment.CurrentManagedThreadId not found", but yours may be slightly different.  The point is, developing and building with 4.5 followed by deploying to a server without 4.5 will cause a problem.  The end.

Or not.  I wouldn't leave you without a solution (or two)!  Well, I might leave you without a solution, but this blog is about keeping track of fixes I've used so that I can reference them in the future and I wouldn't leave myself without a solution.  Our solution was to deploy 4.5 to our web servers.  That worked fine and honestly didn't blow anything up; honest!  According to Marc Gravell, you could also place the reference assemblies for 4.0 on the web server in the reference assemblies folder.  Since I haven't tried that solution I can't endorse it, other than to say that Marc's answers are always helpful and (as far as I can recall) correct as well so I trust him.

That's it!  That's the story of The Day 4.5 Broke Our Build.  The End.

No, seriously this time.  That was it.

Go home now.

There's nothing else to read here.

OK, fine here's another kitten picture.