How's this for obscure? Our solution contains a .dbproj file, which for those not in the know (including me up until about three days ago), is a type of project that is added when you install Visual Studio Team System for Database Professionals (pka DataDude after the legendary surfer that built it). We also use Cruise Control on a build server which does *not* have Visual Studio Team System for Database Professionals installed.
The issue was that the build would fail on the build server because of some reference to VSDBPro in the dbproj. Specifically:
D:ccnetprojectsCritterClassifierSourceDatabaseEHTDB.dbproj(75,11): error MSB4019: The imported
project "C:Program FilesMSBuildMicrosoftVisualStudiov8.0TeamDataMicrosoft.VisualStudio.TeamSystem.
Data.Tasks.targets" was not found. Confirm that the path in the <Import> declaration is correct, and
that the file exists on disk.
No problem, says you, why not simply ignore the project in the configuration that the build server uses? Well, says I, don't be actin' all high 'n mighty 'til you gone done tried it yerself! If you do, you'll discover that the error still occurs, although it doesn't actually cause the build to fail. (Yeah, it sounds whacky but I ain't elaboratin' so you'll have to try it to see it in action.)
The error doesn't actually occur when the project is compiled, mostly because the project isn't compiled during the build. It happens when the .dbproj file is loaded. (NOTE: We're using msbuild against the .sln file.) Opening the .dbproj file in a text editor, you'll see:
My fix: add a Conditional attribute to the <Import> element:
This tells whomever is parsing this sucker not to import the project if the file doesn't exist. Of course, you won't be able to compile the project in this case but the build server doesn't need to know that...
Kyle the Finagled
P.S. Another potential fix is to compile the projects with NAnt instead of MSBuild, which I think is preferable if you can get away with it.