Continuous Integration
Build Report Will Not Show in CCNET
Feb 12th
Ok, stupid … but time consuming.
If you edit your dashboard.config in CCNET to incldue NCoverExplorer details and for some reason the report NEVER SHOWS you need to do the following:
- Restart the CCNET Service
- Reset IIS (iisreset command)
I forgot to do #2 and for an hour and a half I banged my head against the wall trying to figure out what was going on.
Oops.
Excluding Integration Tests from your Automated Build
Feb 9th
A simple tip to exclude certain tests from running during your automated build.
In this scenario we have a bunch of tests inside of a particular DLL. Inside of these tests we have a folder that is for “integration tests”. These tests are run usually once a day in a nightly build and are also run on a developers machine to ensure they didn’t break anything from an integration standpoint before checking in the code.
What we want to do is exclude the tests from running in our CC.NET continuous integration build environment. This is real simple to do by just following a couple of simple steps.
- Categorize your tests as “Integration” (or whatever you want to call them). I prefer “integration” because it signifies exactly what they are.
- Exclude them via the NUnit2 task in the NAnt build script.
Example code:
[TestFixture, Category("Integration")]
public class OrderServiceIntegraitonTests
{
// a slew of tests go here ...
}
Then in your NAnt file do something similar to the following to ensure these tests are excluded for the continuous integration build:
<nunit2 failonerror="true" >
<formatter type="Xml" outputdir="${results.dir}" usefile="true" extension=".xml"/>
<formatter type="${outputType}" usefile="false"/>
<test assemblyname="${out.dir}/DF.Example.Tests.dll">
<categories>
<exclude name="Integration" />
</categories>
</test>
</nunit2>
That’s it. By using the exclude element in the NUnit2 task in NAnt you can exclude them.
This is also a command line switch as well, so if you’re not running them in NAnt you can also exclude them via the command line switch, /exclude.
NAnt: SdkInstallRoot has not been set
Jan 14th
I’ve had this error pop up nearly 20 times when setting up CCNET through the years. Unfortunately I never notated what I had to do to fix it. I usually just spent 20 minutes banging my head against the wall trying to figure it out. Then when I finally do figure it out I never notate it down. Well, this time I’m going to notate it here so I can fix it next time real quick and hopefully someone else will find this useful through “teh internets” as well.
The Error
BUILD FAILED
Failed to initialize the ‘Microsoft .NET Framework 2.0′ (net-2.0) target framework.
Property evaluation failed.
Expression: ${path::combine(sdkInstallRoot, ‘bin’)}
^^^^^^^^^^^^^^Property ’sdkInstallRoot’ has not been set.
Expression: ${path::combine(sdkInstallRoot, ‘bin’)}
How to Resolve
Open the nant.exe.config file and scroll down until you find this entry.
<readregistry property="sdkInstallRoot" key="SOFTWARE\Microsoft\.NETFramework\sdkInstallRootv2.0" hive="LocalMachine" failonerror="false" />
You’re going to replace the Key with this:
<readregistry property="sdkInstallRoot" key="SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.1\WinSDKNetFxTools\InstallationFolder" hive="LocalMachine" failonerror="false" />
We’re changing the location of the sdk’s install root.
Now, everything should be gravy. Key word: SHOULD
The Importance of Incremental Builds
Oct 15th
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:
- Clean – When Team Foundation Build performs a full build, it cleans the files in the intermediate build folder and sources folder in Clean target.
- 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.
- 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:
- Open the TfsBuild.proj file for the build in question
- 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.
Dependency Walker & SP1 TFS 2008 Upgrade Issues
Oct 10th
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
- Installed VS 2008 SP1 to update Team Explorer
- Tried to install TFS 2008 SP1 to update TFS
- Fatal Error Occurred.
- Traced back the dependencies to Dependency Replicator was blocking the web publishing (seen above)
- Stop and Uninstall Dependency Replicator
- Install TFS 2008 SP1
- Restart
- Re-Install Dependency Replicator
- Done