Some of the brilliance of MSBuild includes recognizing when source files have not changed and therefore avoiding a re-compile. However, despite possessing an OutDir property, MSBuild always uses the /obj/Debug (or /obj/Release) directory to perform the comparison. MSBuild uses this directory as a temporary folder to avoid contention issues. In our case, our compiled DLLs reside in a separate directory named /build. Thus, with MSBuild writing DLLs into the /obj/Debug directory, it would always rebuild the DLL (thinking it didn't even exist). These "modified" DLLs would be checked into source erroneously. To overcome this, I interrogated the Microsoft.Common.targets file to see what the MSBuild team was doing. (This file sits in [Windows]\Microsoft.NET\Framework\v2.0.50727) To truly override the output directory, I'm using the IntermediateOutputPath and BaseIntermediateOutputPath properties. My MSBuild looks something like this:
I'm excited to be named to TeamFB for FinalBuilder! This is similar to Microsoft's MVP program. I suppose I bugged them with enough questions they figured, "Give him some work to do". Anyway, I think this is a great product and look forward to helping other developers implement this technology.
My latest project involves creating an automated build solution for .Net 2.0 source code. For the solution, we're using MSBuild, Cruise Control.Net, and a commercial product called FinalBuilder . I'll write up a later post outlining the approach/solution but I just wanted to recommend FinalBuilder. It's a great build orchestration solution both on the desktop and the server. It also integrates with CruiseControl.Net, extends via Java/VBScript, COM components, or .Net assemblies (called Custom Actions), and their support rocks. I've been active on their newsgroups while constructing my client's solution. My FinalBuilder posts .
Whew. I'm finally past this troublesome TFS project creation error. At first in my research, I discovered TFS is (somewhere... RegProxyFileCache.xml I think ) configured to look for WSS (Sharepoint) Admin at port 17012. Some folks identified a second install of WSS leads to the incorrect port for WSS ...thus causing a TFS project creation error. This was not the case for me. Finally, upon highly scrutinizing the project creation log file, I found an inner, inner, inner exception reading: Exception Message: The request failed with HTTP status 403: Forbidden. Checking IIS on the TFS instance for the "Sharepoint Central Administration" site, I opened the Directory Security tab. Sure enough, the "IP address and domain name restrictions" option was set to default deny and only granted to localhost (127.0.0.1). Ugh. Security. ;-) To resolve, I simply set the option to default grant. Project creation successful! I hope this helps someone avoid this issue.
Microsoft's marketing engine IMO, missed the mark branding and naming Team System. (To their defense, it's tough to understand this product line and communicate its vast functionality.) I've seen these products referred to as Team System, Team Suite, Team Edition, and a host of other monikers. To help clear up the confusion, here's a brief write-up and a link to Wikipedia which [I hope] offers a clear explanation. Visual Studio 2005 Team Edition - The Integrated Development Environment (IDE) technology workers use to accomplish work. There are five "editions", each targeted to a particular role: Visual Studio 2005 Team Edition for Software Developers Visual Studio 2005 Team Edition for Software Testers Visual Studio 2005 Team Edition for Database Professionals Visual Studio 2005 Team Edition for Software Architects Visual Studio 2005 Team Suite - This edition encompasses the functionality of the other four. It's an extra $1200 but I recommend it. The cr