|Home||Back to Index|
This one cost me an hour or so of investigation.
I had installed the Unity Application Block straight to a Team Foundation Server (TFS) local workspace folder, then checked the binaries into source control. In a project, I added a reference from the Browse tab. This built fine locally, but did not build on our CruiseControl server. The .csproj file did not have a HintPath entry for the reference, so the build server couldn’t find the DLL.
Apparently if you reference an assembly through the Browse tab that is listed in the .NET tab of Visual Studio’s Add Reference dialog (which is not the same as the GAC) and that is in the same install location, Visual Studio will assume that you want to use the Registry to find the file. I think it sets Specific Version to True in properties, which is the only way you’ll notice it in the IDE. This prevents anyone else from compiling it, even if they have the same DLLs in the same location, unless they’ve run the installer for that package.
I ended up uninstalling the block with Add/Remove Programs, then getting the binaries again from TFS. Removing and re-adding the references fixed the problem.
This is with Visual Studio 2008 (pre-service pack), too. We used to have problems with VS 2005 “helpfully” finding missing references (usually in some bin folder) and silently adding them to our projects.
When will Microsoft figure out that developers need total control over build scripts? If I say “project, get this assembly from this location” and the file isn’t found at build time, fail the build. At the very least, give us an option (as a coworker suggested) to turn “smart” behavior off.
Just another reason to like NAnt…
P.S. We set up CruiseControl to run NAnt, but the NAnt scripts call MSBuild to compile the solutions. This permits developers to maintain projects visually.