With continuous integration being integrated into Team Foundation Server 2008 we can sometimes run into unexpected results. Such as extended build times.  By default the build file is set up to inform the TFS Build Agent that it should perform a "Full Build".

What is a "Full Build"?

By default, when TFS performs a build the following events happen:

1. Clean - When Team Foundation Build performs a full build, it cleans the files in the intermediate build folder and sources folder in Clean target.
2. Workspace Initialization - As a part of a full build, Team Foundation Build deletes the old, and recreates a new workspace to clean and synchronize the source files.
3. Get - In the Get task, Team Foundation Build by default retrieves new source files and overwrites the existing files in the build workspace.

A Possible Issue

A full build can have consequences that can be considered "non-optimal" (this is very subjective in many circles), but in my opinion coming from a Cruise Control .NET background, I DO NOT want full builds.

If my source code repository is very large, cleaning the files, re-creating the workspace and then getting all the files again can be a real pain in the "time" category. I've had builds on my local dev machine (which is in a VPC) take 15-20 seconds to build using Visual Studio. I've even run the same build from the command line using MSBuild using the .proj file and its taken less than 15 seconds for he same build (~15 Visual Studio Projects in the solution).

However, this same build using TFS would take nearly 20+ minutes!

Wowzers... The reason the build took so long in TFS is because it was utilizing the FULL Build.

Core Concept

One of the core concepts is "Keep The Build Fast". We're looking for frequent feedback. 20 minutes (IMO) is not quick feedback (if the build takes 15-20 seconds on my machine). We should be able to get this down to under 10 minutes at the worst, but my goal is to get it well under 5 minutes (closer to 2 minutes).

Enabling TFS 2008 Incremental Builds

In Team Foundation Server 2008, we can change this behavior with a simple change in the TfsBuild.proj file under the TeamBuildTypes directory in TFS. Here's how:

1. Open the TfsBuild.proj file for the build in question
2. Add the following XML:

This will enable Team Build to treat this build as an incremental build.

What does this exactly do behind the scenes?

IncrementalBuild is a convenience property that sets SkipClean to true, SkipInitializeWorkspace to true, and ForceGet to false.

Since clean is skipped, the files will not be deleted. Since SkipInitailizeWorkspace is skipped, the workspace will not be deleted and recreated and since ForceGet is disabled, the files will not be overwritten with the files from Source Control. What this will do is perform a regular "Get" on the existing workspace which will only get the changed files.

Result

A huge performance improvement. The previous ~20 minute build dropped to about 4 minutes. There are some other improvements I could do to improve the performance,but at this time its 5 times as fast. Excellent. :) Why did it improve this much? Simple: Less disk I/O. Disk I/O = slow.

Disclaimer: This may not be desired. For example, build that is specified for "Production" you might want a "Full Build" in order to simulate a production release. You may have tasks in your build file that need a clean build. But for Continuous integration on the project, this setting is highly desirable.

My plan today was to upgrade Team Foundation Server 2008 to Service Pack 1 (SP1) today. My client runs a dual server implementation and we run Team Explorer on the App Tier of this set up. Therefore we needed to upgrade Team Explorer and TFS itself to SP1 for 2008.

Round 1

The TFS SP1 Documentation states the following -

"...you should first install SP1 for Visual Studio 2008 and then install SP1 for Team Foundation Server on any server that is running both Team Foundation Server and Team Explorer. If you try to update Team Foundation Server first, the update will fail. If you update Team Foundation Server but not Team Explorer, you will encounter errors if you try to use that installation of Team Explorer to perform certain administrative tasks on Team Foundation Server. "

Makes sense. Install SP1 for Visual Studio 2008 and then move to SP1 for TFS. So we did...

Upon installing SP1 for Visual Studio we had to reboot (for whatever reason) ... upon reboot services failed to start and we were notified. Upon further investigation in the event viewer we found the following entries:

"The configuration data for this product is corrupt."

and

"TF30059: Fatal error while initializing web service ..."

and

"TF53010: The following error has occurred in a Team Foundation component or extension: ..."

Plus, inside of the event viewer I was seeing that TFS was "Crashing" and a crash report was being generated for Microsoft. I did some searching and found this blog entry (thanks Tom) and noticed that he was having a very similar problem. The blog recommended that we install SP1 for TFS as this was the hot-fix as listed here by Microsoft. Apparently there is a problem with SP1 Explorer components and NON-SP1 TFS components.

No problem, right? Lets install SP1 for Team Foundation Server 2008. Nah, nope, didnt work: FATAL ERROR. Again, baffled, back to the drawing board.

Round 2

Upon further looking into the service errors it was brought to my attention that the IIS Admin service was NOT starting. Running "iisreset" from the command line didn't do anything either (other than giving me a FAIL finger). It would fail stating that one of the dependencies wasn't starting up. I looked up the dependencies and noticed this:

I also noticed that the service Dependency Replicator was failing as well. Ok, so this makes sense... if Depdendency replicator failes, then everything else fails in the dependency tree. I had installed this service to help with some continuous integration stuff I'm doing for the client.

The Solution...

I removed this service (completely uninstalled it). Then tried to start IIS. It worked. Cool.

We then tried to start the TFS Services. Nope. Failure still. But now, the symptoms were EXACTLY the same as noted this blog entry.

We then kicked off the TFS 2008 SP1 installation and then tried to start the TFS Services again. SUCCESS!

I then re-installed Dependency Resolver and everything started working as normal. No errors.

Root Cause

In the TFS installation guide the following is noted:

"... If you update Team Foundation Server but not Team Explorer, you will encounter errors if you try to use that installation of Team Explorer to perform certain administrative tasks on Team Foundation Server... "

Essentially the guide is stating "if you update one, but not the other, then it won't work". This is exactly what happened. I haven't tapped into the TFS Dependency Replicator Code base that much but I assume that it uses some components that are shared between Explorer and TFS. When this mis-match occurred it broke.

RE-Cap - Events & HOW TO FIX

1. Installed VS 2008 SP1 to update Team Explorer
2. Tried to install TFS 2008 SP1 to update TFS
3. Fatal Error Occurred.
4. Traced back the dependencies to Dependency Replicator was blocking the web publishing (seen above)
5. Stop and Uninstall Dependency Replicator
6. Install TFS 2008 SP1
7. Restart
8. Re-Install Dependency Replicator
9. Done

_PublishedWebsites does not exist?! WHAT?! Huh?

One of our TFS builds was succeeding and a fellow developer noticed that the Web App was not getting copied into the _PublishedWebsites folder of our drop location.

I took a look at our TFSBuild.Proj file and I didn't see anything that stood out. I took a look at a similar project who's output was being copied into the _PublishedWebsites directory and the .proj file matched that of the one that did not work.

Solution

The problem was not in the .proj file, but in the actual .csproj file for the Web Applicaiton Project.

.csproj files ARE MSBuild files and inside of that I saw this:

<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<!--<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v8.0WebApplications\Microsoft.WebApplication.targets" />-->

The second Build target file was not getting loaded.

This build target file contains a target by the name of "_CopyWebApplication" which takes the output of the web application and copies it to the _PublishedWebsites directory.

I uncommented this line, checked it back into TFS and re-ran my build and my _PublishedWebsites started showing up. :)

My file now looks like this:

I recently help set up a CI (Continuous Integration) environment using CC.NET (Cruise Control.NET) at a client that I'm at. We're in the process of implementing TFS (Team Foundation Server) but until some red tape is cleared we're still stuck on VSS (Visual Source Safe).

While setting up the environment we were given a test VSS account to work with until everything worked as expected. Well the user they gave me had a blank password.

Example -

User: ccnet Pass: (no password)

The visual source safe source control block looked like this:

<sourcecontrol type="vss" autoGetSource="true" applyLabel="true">
   <executable>C:\Program Files\Microsoft Visual Studio\VSS\win32\SS.EXE</executable>
   <project>$/CCNET</project>
   <username>ccnet</username>
   <password> </password>
   <ssdir>c:\repos\</ssdir>
   <workingDirectory>c:\myBuild</workingDirectory>
   <culture>en-us</culture>
   <cleanCopy>false</cleanCopy>
</sourcecontrol>

When I fired up the CC.NET Service, everything started off fine. The project said "Checking For Modifications" and then it HUNG there, forever. It never stopped. I had to stop the service and then kill SS.exe (source safes process).

Solution

The reason this happened is because of this line:

   <password> </password>

The password was left as " ". It was a space. If I fired up VSS and typed in ccnet and put a space into the password, it would let me in, no problem. But if I did that with CC.NET SS.EXE would hang.

Pretty much, here's what's happening - Source Safe is firing up and its trying to log in and its giving an invalid password. SS.EXE is trying to raise a dialog box, but its running under the context of the Cruise Control.NET service, therefore it cannot open that dialog box.

I changed the password field to this:

   <password></password>

and then it worked flawlessly.

Simple solution to a simple mistake. :)

Jeremy D. Miller has a great post on keeping source code where it belongs. The thought process behind this is that code should be where YOU would assume it would be. If its data access code, it should be in a project/namespace that is something like Data Access or DAL or Data or something that represents the lower layer of the architecture. If its the business rules/tasks the files should be in a project called Business Rules, or BLL, or Tasks, or something similar. It makes sense, just think about this -- if you walk into a business and are given a project that was created by another developer and you're getting a ADO.NET Exception, you'd expect to find the code Data Access code in a Data Access layer, NOT in the code behind. I should not have to hunt down where you put your data access code.

We're talking about basic separation of concerns. The thing is, many developers lack these concepts because they're under the assumption of "I can write this the correct way, and it will take me 2 weeks, or I can do it quickly and it will take me 2 days." This may not matter when the application is running for a few months, but when you are asked to change the data provider from SQL Server to Oracle, or remove the web service calls and replace them with RPC calls, you're going to find yourself in a world of hurt because you didn't set everything up correctly. At this point they have amounted a large amount of Technical Debt.

He also noted that a large number of people were now using Ruby On Rails (RoR) as their development platform and I won't deny that I also believe that Ruby/Rails is huge right now. Tons of shops are running RoR and even Martin Fowler said on Hansel Minutes that ThoughtWorks was doing about 40% (or more) of their business with Ruby. The key point Jeremy brought up is that "RoR forces web developers into a bit of a straight jacket, but that's a good thing in a way." I completely agree. RoR enforces a consistent source code tree layout which allows for developers to easily find there way around a project. "Developer A" can create a project with RoR and then "Developer B" can come along and take a look at it and be familiar with the code layout and structure. The RoR community has agreed that this is the basic way to organize a project and it seems to be working for them.

So what about .NET? Enter Tree Surgeon. Right now, its a stand alone application, but in its near future it should be implemented as a template in Visual Studio 2005/2008. So what is it? It's a application that will create that straight jacket that Jeremy spoke of. It gives the developer a basic set up of layers, unit tests, code coverage and build script. It builds the entire source code directory and allows you to build on top of it. The source code layout follows a white paper written by Mike Roberts. I've been using it for quite awhile and I'm one of the developers on the project. I recently updated the source to allow creation of Visual Studio 2005 projects. Please note, this is only on the source and has not been reflected on the production release. Download the source, run it and then choose a application name, and generate the project source directory tree. Open the solution file and your application is ready to go.

The best part is that its easy to integrate existing projects into this format. I've done it quite a few times to allow for easy integration into my clients CI environment.

If you have any requests for Tree Surgeon, please visit the Issue Tracker page and submit and issue.

Enjoy!

Over the weekend I had the time to work with Teamprise Explorer and Visual Studio Team Explorer while working on an open source project that I'm a part of. This was the first time I've worked with Teamprise explorer and Visual Studio Team Explorer. Since Codeplex houses its source on Team Foundation Server (TFS) I was required to use one of these options. This is a little look into my experience.

First off let me start by saying that I'm a Subversion junkie. I keep all of my own personal source code in Subversion and I've helped many clients implement Subversion in my time. I'm an avid user of TortoiseSVN because of its ease of use within Windows Explorer. Working with TFS was very similar to that of Subversion but the terminology was different and in my opinion Teamprise was a little more difficult to use. I originally wanted to use the Visual Studio Plug-in but I didn't want to wait for the 246 MB file to download so I could install a plug-in. :\ Therefore, I went with Teamprise first. They will give you a free license to work with Codeplex if you're working on a project, so that was a win/win for me.

Teamprise Explorer Client will allow you to connect to a Team Foundation Server to access source code (its user interface reminds of me of WinCvs quite a bit, yet  a lot more polished than that of WinCvs). The only problem that I had with Teamprise is that when I went needed to edit the code I had to "Checkout for Edit". If I did this on the entire directory tree such as my "src" directory it would log everything in edit mode. Therefore, when I went to upload the changes the entire source tree was being uploaded. NO BUENO. I know that on average I like to see what I've edited (yes, I'm used to TortoiseSVN) in some type of explorer window. This didn't happen on Teamprise (maybe there is a way to see if a file has changed other than the Pending Changes window, if so, someone please let me know). In the end, I got frustrated, ended up clicking some button on Teamprise explorer and overwrote all my changes somehow. THAT SUCKS. I got frustrated and decided to download the plug-in and start working that way.

Visual Studio Team Explorer Plug-in was great. Its interface reminded me of the old days when I use to personally use Source Safe 6.0. The icons were similar and it was familiar ground. I think we may have a winner. After making my changes again I was able to easily see what changed through simple icon's changing colors and I checked everything in really easily. It was very seamless. The only downside to Visual Studio Team Explorer is the install process. First you have download an IMG file, then download an install an IMG extractor and then open the IMG, then install. Only then did I get the full Visual Studio Integration. Very nice.

One downside that I see is that the Express SKU's don't allow plug-ins so this kind of sucks for those guys. How can you have an open source hosting site that doesn't allow its users to easily get the source. Don't get me wrong, they can use Teamprise but they have to know there is a learning curve with that. I didn't have the patience for it this time around.

There is hope on the horizon though...

CodePlex will be offering TortoiseSVN Support to Team Foundation Server. Therefore you will be able to use a tool such as TortoiseSVN to access Team Foundation Server. Supposedly this is to be released on or around June 18th of this month. In a nutshell there will be a bridge built between SVN Commands and TFS commands. I would assume this is a good place for the Adapter pattern to be put to work.

Hopefully this comes to fruition, I can see a lot of people possibly moving their projects to CodePlex if that's the case.

As of a couple weeks ago, I joined the Tree Surgeon open source project. Recently, Bil Simser took over the project and opened it up on CodePlex. The development team will be adding many new features to the application to help in the setup of the development tree structure and build integration process. Keep your eyes peeled!

Problem

The .NET Framework reference in the most recent release of Tree Surgeon has an old reference to .NET 2.0 Beta 1. This is in the NAnt.exe.config file.

This will produce results that will not compile when using the <msbuild> task of the NAntContrib Tasks.

Fix

Open the file located in "ProjectName/Tools/nant/NAnt.exe.config" file.

Find this:

<framework 
   name="net-2.0" 
   family="net" 
   version="2.0" 
   description="Microsoft .NET Framework 2.0 Beta 1" 
   runtimeengine=""
   sdkdirectory="${path::combine(sdkInstallRoot, 'bin')}" 
   frameworkdirectory="${path::combine(installRoot, 'v2.0.40607')}" 
   frameworkassemblydirectory="${path::combine(installRoot, 'v2.0.40607')}"
   clrversion="2.0.40607"
>

Then replace it with this:

This will fix the issue and allow you to remove the <solution> task from the default build file that is included in each project generation.

You will now be able to utilize the <msbuild> task in the NAntContrib. See below:

Mike Roberts over at ThoughWorks have a project to help with continuous integration.

The product is called "Tree Surgeon". Tree Surgeon solves the problem of how to set up a development tree.

"Tree Surgeon is a .NET development tree generator. Just give it the name of your project, and it will set up a development tree for you in seconds. More than that, your new tree has years worth of accumulated build engineering experience built right in."

What the product does is it allows you to specify a project name and the application will create a development tree for you (code generation). This tree includes a solution, the tools (NUnit, NCover, NAnt) and a build file and script to execute the build. It saves TONS of time when creating a new project and needing to add it to your build.

Example

Creating a new development tree:

This will generate this tree structure:

Inside of the "ExampleApplication Folder" we have the build and the go script. The "go" script compiles, runs NUnit and NCover. Its the workhorse of the system. Run this from the command line. If you want to see the results while in a command window, I'd advise editing the go.bat file and adding @pause at the end of the script so you can see the results before the window closes.

The solution for the project is located in the 'src' directory:

You can execute the go.bat file and it will complile, and run NUnit and NCover on your application.

The best part about this is that its all configurable. Edit the cs.vm files in the C:\Program Files\Tree Surgeon\Resources\Templates directory and you'll be able to affect the output of the code generation. Plus, its all open source, so you can get the code from the site.

This could help a lot of companies get up and running with a development tree in their source control.

*Note: Currently Tree Surgeon only exports C# files.

I'll be writing more about Source Control Management as time continues... stay tuned.

For those of you who use Simian, please be aware, they upgraded the product and the old "-recurse" option no longer works. Read below on how to fix it.

The Issue

I downloaded it last night to test it with my teams current continuous integration environment through Cruise Control .NET (CCNET).  I looked at some examples on the CCNET website on how to run this as a NAnt task and found that it should be fairly easy. I just needed to recurse through the directories and have it run on all C# files (*.cs). Unfortunately I was getting a "Invalid Option" each time I ran this code:

simian-2.2.13.exe -recurse=*.cs -formatter=xml:simian.xml

The Issue, Part 2

I finally figured out that the docutmentation on the CCNET site was incorrect. The new product removed the -recurse option and replaced it with -includes and -excludes options to resemble the file globbing method of retrieving files.

I then ran the command as they recommended on the site:

I then got this error: "Error: Illegal characters in path."

The battle continues

I continue to battle this until I finally give up I try wrapping paths in quotes, executing using different syntax, passing in different wild cards. I combed the documentation with a fine tooth comb, only to find, NOTHING.

Resolution

I resorted to emailing support to ask for help.

To my amazement, I had a reply within 2 hours stating that I found a bug in the new release. They said they would fix it and upload a new version ASAP. 5 Hours later, the new version was live on the site.

I downloaded the new version, version 2.2.14, and ran the command

simian-2.2.14.exe -includes=**/*.cs -formatter=xml:simian.xml

I ran the command and the system placed my results into my requested XML File. I was now able to integrate it into my continuous integration system.

With it in place, I can now see my similiarity results.

Cruise Control .NET Website support link