Same MSBuild file, different results on local machine and CCNet

Question

Background

I am utilizing the following:

• VS 2012
• .NET 4.5 apps including an MVC4 app, a C# Domain app, and NUnit projects.
• A custom MSBuild File
• CruiseControl.NET running on a build server

I have the following build targets:

• Clean: deletes the buildartifacts directory
• Init: creates a blank buildartifacts directory
• Compile: compiles the solution
• Test: runs NUnit Tests
• Package: creates a ZIP package for deployment
• Deploy: Deploys package to a remote IIS Server

Problem

• When I run the build from my local machine, it packages and deploys perfectly.
• When CCNet runs the same build target, the files appear to be deployed

Attempted Resolutions / Potential Leads

• I have run the same target in PowerShell from both machines and have seen no errors or warnings on either.
• Because I tell CCNEt to override the framework to point it to the .NET 4.5 files I've copied to the build server, I made my local machine point to the same files when running MSBuild but my local build still worked and deployed.
• In Visual Studio, I have ensured that all content files are marked with a Build Action of "Content" and a Copy to Output setting of "Copy Always".

The Code

• Available in a gist at https://gist.github.com/53ef2a63931d190593f6
• (file has been scrubbed, app name & credentials replaced, etc.)

Answer 1

It turns out, this was a completely unrelated issue.

After doing a diff of both build logs, I noticed that the build server working copy contained old files that no longer existed. This led me to discover that the issue ended up being that the repository wasn't being updated.

CCNet was receiving a subversion error that wasn't registering as an error As a result, I was never getting the latest version of the repository, and so all files were broken.

The error is related to this StackOverflow question, regarding a sqlite error when attempt to use tortoisesvn to update. The solution in my case was to simply delete the build server's working copy, recreate the folder, and perform an svn checkout.