Jim Lamb

How to Build Compact Framework Projects with TFS 2010

JimLamb — Fri, 13 Nov 2009 20:32:00 GMT

If you have a Visual Studio 2008 solution with one or more Compact Framework (also referred to as “Smart Device”) projects that you’re trying to build with TFS 2010 or MSBuild 4.0, you’ve probably hit one of the following errors:

error MSB4062: The "Microsoft.CompactFramework.Build.Tasks.AddHighDPIResource" task could not be loaded from the assembly Microsoft.CompactFramework.Build.Tasks

Or,

error MSB4062: The "Microsoft.CompactFramework.Build.Tasks.GetDeviceFrameworkPath" task could not be loaded from the assembly Microsoft.CompactFramework.Build.Tasks

The problem is a setting in the application configuration file for MSBuild (MSBuild.exe.config), which you’ll find in your .NET Framework directory (e.g. “C:\Windows\Microsoft.NET\Framework\v4.0.21006” for x86 systems or “C:\Windows\Microsoft.NET\Framework64\v4.0.21006” for x64 systems).

You’ll need to remove this element:

<dependentAssembly>
  <assemblyIdentity name="Microsoft.CompactFramework.Build.Tasks" 
    publicKeyToken="b03f5f7f11d50a3a" 
    culture="neutral"/> 
    <bindingRedirect 
      oldVersion="0.0.0.0-99.9.9.9" 
      newVersion="10.0.0.0"/>
</dependentAssembly>

This will stop MSBuild from trying to load the non-existent 10.0 version of the Microsoft.CompactFramework.Build.Tasks assembly.

Upgrading TFS 2008 Build Definitions to TFS 2010

JimLamb — Tue, 03 Nov 2009 20:48:52 GMT

If you’re a TFS 2008 user who’s thinking about installing TFS 2010 Beta 2, you may be wondering what will be involved in getting your existing build definitions to work in 2010. You see, build definitions in TFS 2008 are entirely automated using MSBuild. Whereas build definitions in TFS 2010 only use MSBuild for source code compilation and use Windows Workflow to orchestrate everything else that happens during the build process (setting up the workspace, running tests, indexing sources, copying binaries to the drop folder, associating changesets and work items, etc.). We refer to this workflow (it’s actually a XAML file) as a build process template. Naturally, you may have some questions about how this will affect your investment in automation your TFS 2008 builds.

Here are answers to some of the most common questions I’ve heard so far. Please let me know if you have any other questions.

Will my TFS 2008 build agents work with a TFS 2010 server?

No, they won’t. You’ll need to install the TFS 2010 build service. It’s included in the same setup as the TFS application tier and you would generally set it up on a dedicated build machine. If you’re just doing nightly builds, however, and not doing a steady stream of continuous integration builds, it’s fine to install it on the same machine as your application tier. I recommend reviewing the help topic on Understanding a Team Foundation Build System before deploying more elaborate build infrastructures. After upgrading from TFS 2008 and setting up build services for TFS 2010, you’ll want to review each of you active build definitions and set the default build controller appropriately (see the Defaults tab of the Build Definition editor).

Can I install the TFS 2010 Build Service on my TFS 2008 build machine?

Yes, you can. Even though they both default to the same port (9191), they can share that port without any problems.

What do else will I need to install on the build machine?

It depends on what you’re building. If you install the TFS 2010 build service on a clean machine, it will install the .NET 4.0 Framework which includes MSBuild. It will also install the components necessary to support the following:

Code Analysis
Unit test execution with MSTest
Architectural layer validation
Database schema deployment and test data generation

Unfortunately, the .NET 4.0 Framework is missing some of the tools necessary to build projects targeting the .NET 2.0 and 3.x Frameworks. For Beta 2, you can install the Windows SDK or Visual Studio 2010 Beta 2 on the build machine. If you need to build SharePoint or Office (VSTO) projects, you’ll need to install the appropriate SDKs or Visual Studio.

Will I need to redo my build definition?

No, you won’t. TFS 2010 includes a special Upgrade build process template that mimics the behavior of TFS 2008 builds by invoking MSBuild on your existing TFSBuild.proj file. TFS 2010 will even let you use new features like gated check-in and shelveset builds.

Should I convert my build definitions to use the Default build process template?

The default build process does make it easier to make certain customizations to your build definition using build process parameters.

Can I keep using my custom MSBuild tasks?

If you’re using the Upgrade build process template then, yes, you absolutely can continue using your MSBuild tasks. If you choose to use the Default build process template for new build definitions, the answer is a little more complicated. For actions you want to perform during the compile phase of your build, you can customize any of the projects getting built to use whatever custom MSBuild tasks you wish to use.

If, however, you want to perform actions at some other stage of the build process (e.g. after running tests), it becomes trickier to invoke an MSBuild task. You would need to create a special .proj file invoking the custom task you wanted to use and modify the build process template by adding an MSBuild activity that builds your that .proj file. Alternatively, you could create a custom workflow activity to do what you need to do and integrate that into your build process template. I’ll have blog post up later this week covering that topic in detail.

If I’m not ready to upgrade to TFS 2010, can I build my VS 2010 solutions/projects with TFS 2008?

Yes, here are the steps to configure the TFS 2008 Build Agent to use MSBuild 4.0 to build your VS 2010 solutions:

Navigate to this folder on the TFS 2008 build agent:

<program files>\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\TFSBuildService.exe

Open the TFSBuildService.exe.config file.
Search for the MSBuildPath appSetting.
Set the value to the directory containing the 4.0 version of MSBuild.exe (e.g. “C:\Windows\Microsoft.NET\Framework\v4.0.21006”).

Of course, you’ll need to have .NET 4.0 installed on the TFS 2008 build agent. For Beta 2, I’d recommend installing VS 2010 on the TFS 2008 build agent machine. Let me know if you have any questions.

Have you done anything to about the 260 character limitation on paths?

Sort of. We’ve changed the default working directory for TFS 2010 build agents to <systemdrive>\Builds rather than putting it beneath the build service account’s temporary directory. We’ve also shortened up the overall path to the working directory for a particular build definition to reduce the odds of you hitting the 260 character path limitation in Windows.

What Everybody Ought to Know about the TFS SDK

JimLamb — Fri, 30 Oct 2009 03:49:14 GMT

If you’ve checked out the latest Visual Studio SDK, you may have noticed something relative to the previous releases:

SDK Release	Download (MB)
Visual Studio 2005	124
Visual Studio 2008	109
Visual Studio 2010	10

So, where’d the other hundred megabytes go? On-line – that’s where. The latest Visual Studio SDK really only contains the core content necessary to build new VSIP packages and other extensibility projects. All of the documentation and samples have been moved to their new home on MSDN Code Gallery.

Of course, that includes the Team Foundation Server 2010 Beta 2 SDK samples and documentation. It also includes a starter set of code snippets which aren’t full-on samples, but give users programming against our object model quick, narrowly scoped answers to common implementation questions. Lastly, there’s a compiled HTML help (CHM) file that provides some basic documentation on our client object model.

What’s the Plan for the SDK?

We currently have half of the samples that shipped with TFS 2008 RTM updated for 2010 Beta 2 and published to Code Gallery. Due to some recent API changes, these will require additional updating prior to RTM. The remaining work is as follows:

Finish updating remaining samples and publish to Code Gallery
Review XML documentation comments in public object model API
Coordinate with our technical writers to deliver API documentation for MSDN
Identify, author and publish new samples and snippets as appropriate

If there are particular samples or snippets that you’d like to see, post a comment or drop me a line.

Enabling Symbol and Source Server Support in TFS Build 2010 Beta 1

JimLamb — Mon, 15 Jun 2009 22:14:01 GMT

One of the really nice new features in TFS Build 2010 is support for symbol and source server. While the names “Symbol Server” and “Source Server” are somewhat misleading (there isn’t really a separate server involved), the functionality is really useful. Symbols are those *.pdb files that get generated by your builds. Those files make it possible to map execution points in your assemblies to their corresponding class and method. “Source Server” support makes it possible for the debugger to locate the correct version of the source file from the version control repository – particularly useful for server builds where the version of a file used in the build may differ from the version in your local workspace.

Here are the steps for setting up symbol server with TFS Build 2010 Beta 1:

Create a network share to store your symbols (e.g. \\server\symbols) – the symbols beneath your drop folder are effectively copied to the symbol store location so that they’re available even if your drop folder isn’t
Grant the build service account write permissions to that share
Grant your team project contributors read access to that share
Edit your build definition and, on the Process tab, set the Index Sources parameter to true and the Path to Publish Symbols parameter to the UNC path of the symbol share you created

To use the symbols generated at build time, your users will need to do the following in Visual Studio:

Select Tools, Options from the Visual Studio 2010 main menu
Expand the Debugging item in the tree and select Symbols
Add the path to your symbol store (e.g. \\server\symbols) to the list of symbol file locations
Select the General node beneath the Debugging node and scroll down to the “Enable source server support” check box and make sure it’s checked (it’s unchecked by default) – this will allow VS to load the appropriate version of the source file you’re debugging

Now you’ll be able to debug server builds with full symbol and source server support. You’ll also be able to do historical debugging and profiling of server builds. Note that, by default, when a build is deleted due to a retention policy, its corresponding symbols will be deleted as well. You can, however, customize this behavior in the build definition editor’s retention tab.

@Midas79: You don’t need to install the Debugging Tools for Windows on your build machine to use this functionality. We include the required components with the build service install. Also, Aaron Hallberg has a blog post on Writing Custom Activities for TFS Build 2010 Beta 1.

Building a simple web site with VSTS/TFS 2008

JimLamb — Fri, 17 Apr 2009 03:03:21 GMT

I’ve been working on a web site for a local non-profit as an opportunity to spend more time with VSTS and TFS as a user. I setup TFS 2008 SP1 in a virtual machine running on my home PC and made it accessible from the public Internet. I created the web site as an ASP.net web application project and setup an automated build that uses the Web Deployment Tool to deploy the site to a staging server. I have automated unit tests running as part of the build that validate the output of each page in the site using the W3C Markup Validation Service (inspired by Damian Edwards’ excellent Adding HTML validity checking to your ASP.net web site via unit tests post). Over the course of building this web site, I learned a lot about what you can and can’t do with VSTS and TFS and I wanted to share that (somewhat painfully) acquired knowledge with you.

Using the Web Deployment Tool (MSDeploy)

The web deployment tool consists of a console application (MSDeploy) and a Windows service that runs on either the source or target location. I wanted to invoke the tool when the build succeeds, after the output has been copied to the drop location, so I overrode the AfterDropBuild target as follows:

<Target Name="AfterDropBuild">
  <Message Text="This is the AfterBuild target" Importance="normal"/>
  <!-- Insert other tasks to run after build here -->
  <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
      BuildUri="$(BuildUri)"
      Message="Deploying Website"
      Condition="'$(IsDesktopBuild)'!='true'" >
    <Output TaskParameter="Id" PropertyName="InstallerStepId" />
  </BuildStep> 

  <Exec Command="Deploy.cmd $(BuildDefinition) 
    &quot;$(DropLocation)\$(BuildNumber)\Release\_PublishedWebsites\Web&quot;"
    WorkingDirectory="$(SolutionRoot)\Source\Deploy" /> 

  <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
    BuildUri="$(BuildUri)" 
    Id="$(InstallerStepId)" 
    Status="Succeeded" 
    Condition="'$(IsDesktopBuild)'!='true'" /> 

    <OnError ExecuteTargets="DeploymentFailed" />
  </Target>

  <Target Name="DeploymentFailed">
    <!-- Called if deployment of the web site fails -->
    <BuildStep TeamFoundationServerUrl="$(TeamFoundationServerUrl)"
      BuildUri="$(BuildUri)"
      Id="$(InstallerStepId)"
      Status="Failed"
      Condition="'$(IsDesktopBuild)'!='true'" />
</Target>

You’ll notice that the Exec command invokes a command script. I’m not doing anything in that command script that you couldn’t do in MSBuild, but I’m a little more comfortable with batch files, so I chose to implement the deployment steps there as follows:

@echo off
if not %1==FarmersMarket-Nightly goto DEBUG

echo Deploying to production server...
"%ProgramFiles%\IIS\Microsoft Web Deploy\msdeploy.exe" 
  -verb:sync -source:contentPath="%2" 
  -dest:contentPath=C:\Inetpub\wwwroot\FarmersMarket,
    computerName=domain.com,username=domain\user,password=******** > 
    "%2\..\..\..\DeploymentLog.txt"

goto :EOF

:DEBUG
echo Deploying to stage server...
cscript %SystemRoot%\System32\iisweb.vbs /stop "Stage-WesternWakeFarmersMarket"
"%ProgramFiles%\Windows Resource Kits\Tools\robocopy" 
  "%2" C:\Stage\FarmersMarket *.* /E /MIR > "%2\..\..\..\DeploymentLog.txt"
cscript %SystemRoot%\System32\iisweb.vbs /start "Stage-WesternWakeFarmersMarket"

Usernames and passwords have, of course, been replaced with placeholder text. You’ll notice that it branches based on the name of the build definition. My continuous integration build uses robocopy to deploy the build to a test site on my TFS machine while my nightly uses msdeploy to deploy to my remote production server.

Managing the Data (or not?)

At this point, you may be wondering how I’m deploying the database. You may be disappointed to learn that, despite the fact that the msdeploy does support deployment of SQL Server database schemas, I consciously chose to avoid taking a dependency on a database at all. Instead, I chose to you a free blogging service as the ‘backing store’ for my site. I use the Syndication classes in .NET 3.5 to grab content from various feeds I’ve setup and render it on the site after caching it on the server with a rolling timeout. That single decision substantially simplified my deployment requirements. Even better, I can now make updates to much of the site’s content using my favorite blogging tool.

Automated Markup Validation

For my automated unit tests, I simply wanted to validate the XHTML generated by my pages to make sure that I hadn’t broken anything with my changes. Fortunately, Damian Edwards had already done the heavy lifting in this regard and I only needed to make some minor changes to meet my needs. Because I’m choosing to validate each page with an individual test method, I was able to leverage the TestContext object rather than pass in the name of the page to validate to the helper class. Here’s what my test method looks like:

[TestMethod()]
[HostType("ASP.NET")]
[AspNetDevelopmentServerHost("%SolutionDir%\\Web")]
[UrlToTest("http://localhost/default.aspx")]
[DeploymentItem("Web.dll")]
public void ValidateHomePage()
{
  Assert.IsTrue(TestHelper.ReturnsValidHtml(this.TestContext).IsValid,
    String.Format(Resources.W3CValidationFailure,
      TestContext.RequestedPage.AppRelativeVirtualPath));
}

I’ve omitted the test description in the interest of brevity. Also note the user of the %SolutionDir% property where I specify the server host and the missing port number in the UrlToTest attribute (turns out that MSTest will fix-up the port number to match the one dynamically assigned to the web development server).

The next thing I tried was to turn on code coverage. I was surprised to discover that I had to build x86 assemblies in order to get code coverage data. I currently target “Any CPU” since my staging server (also my TFS) is running 32-bit Windows Server 2003 and my production server is running 64-bit Windows Server 2003. Fortunately, that particular gap is addressed in TFS 2010 and you’ll be able to capture code coverage data regardless of whether you’re targeting x86 or amd64.

If you’re interested in checking out my little side project, it’s a web site for the Western Wake Farmers’ Market. Please keep in mind that I’ve radically simplified this project in order to scope it down to something that I could realistically deliver by setting aside just a few hours a week.

Resources for Building ASP.net Applications with VSTS/TFS

JimLamb — Fri, 13 Feb 2009 01:20:17 GMT

I often hear that our customers hit challenges when developing ASP.net applications with VSTS and TFS. I’d like to kick off a dialog with a goal of identifying the key pain points so that we can deliver guidance to eliminate, or at least mitigate that pain.

Managing Web Application Sources in TFS Version Control

Our Patterns & Practices team has a guide on how to Structure ASP.net Applications in TFS. It was, however, originally written for TFS 2005 and assumes that you’re working with a Web Site Project rather than a Web Application Project (see below). Fortunately, working with Web Application Projects in version control is straightforward since they are structured like most other common project systems in Visual Studio. You may also want to review Team Development with TFS and the TFS Branching Guide 2.0.

Generally, you won’t want developers publishing changes to an instance of your ASP.net application directly from their machines unless that instance is in their own personal sandbox. Rather, the automated build should deploy the application to a test or staging environment as appropriate (more on deployment later in this post). Also, be sure to use the tilde (~) in virtual paths referenced in server controls rather than referencing a specific server name so that those paths will resolve correctly on everyone’s machine (including the build machine).

Web Application Projects vs. Web Site Projects

Visual Studio 2005 introduced a new, and somewhat controversial Web Project System that’s now commonly referred to as “Web Site Projects.” Scott Guthrie has provided a thorough overview of that project system. Unfortunately, Web Site Projects are not directly supported by MSBuild and Scott’s original recommendation was to add a “build helper project” to the same solution that you would customize to implement your build process. For many users, however, this solution was less than ideal and in response to customer feedback, the ASP.net team released Web Application Projects in May 2006.

In Visual Studio 2005, Web Application Projects are compiled into a single assembly using an MSBuild-based compilation process. This made it much easier to migrate Visual Studio 2003 web projects to Visual Studio 2005 (and .NET 2.0) while making it possible to build ASP.net 2.0 projects with Team Foundation Server 2005. Visual Studio 2008 included support for both Web Site Projects and Web Application Projects leaving it up to the user to decide which was the best fit for their needs. Maor David provides a succinct summary of when to use which model. Rick Strahl shares his experiences with transitioning to Web Site Projects and Web Deployment Projects in greater depth.

ASP.net Application Deployment

In parallel with the evolution of the ASP.net project system, users were looking for ways to simplify and, ideally, fully automate deployment of their web applications. There were competent third-party solutions for Visual Studio 2003, but there wasn’t anything in-the-box with Visual Studio 2005. The ASP.net team partially addressed this need with Web Deployment Projects which was meant to prepare your application for deployment via the Copy Web Site or Publish Web Site features. Deployment Projects weren’t included with Visual Studio 2008, but support was released in January 2008.

Web Deployment Projects can be used with either “Web Site” or “Web Application” projects in Visual Studio 2005 and 2008. Scott Guthrie has a tutorial on VS 2005 Web Deployment Projects which also applies to Visual Studio 2008, though there are some new features in the 2008 version. There are, however, issues with Team Build and Web Deployment Projects.

Deployment continued to be a pain point for ASP.net developers and Microsoft broadened its efforts to simplify the process by partnering with the IIS team. As of this writing, Beta 2 of the Web Deployment Tool is available for download (in x86 and x64 flavors). This tool creates a package that contains “content, configuration and SQL databases for deployment or sharing with others.” It supports IIS 6.0 and 7.0 and is included with Visual Studio 2010 as well as the Web Platform Installer. We are actively working with the ASP.net and IIS teams to make sure that this tool will work well for teams using Team System and Team Foundation Server.

Building ASP.net Applications with TFS

There are a number of things to keep in mind when building ASP.net applications with TFS 2008. You’ll generally want to install the Development and Test Editions of Visual Studio Team System (or Team Suite). With regard to licenses, your build machine doesn’t need licenses for these (or any) editions of Team System so long as the person creating the build definition in TFS does. You will, however, need a TFS CAL for the build machine. Having the Development and Test Editions installed on the same machine as the Build Agent will enable you to run unit tests and perform code analysis as part of your automated build.

If you are using VSTS/TFS 2005, be sure to apply Visual Studio 2005 Team System SP1 and Team Foundation Server SP1, which includes support for Web Application Projects, to your build machines. If you encounter error MSB4019, you will need to manually copy a targets file to your build machine. You will also want to install Web Deployment Projects for VS 2005 on the build machine if you plan to use deployment projects. If you’re using VSTS/TFS 2008, Web Application Project support is included with the Development and Team Suite Editions of VSTS, but you’ll need to install Web Deployment Projects for VS 2008 on the build machine to successfully build those.

If you plan to run automated unit tests of your web application as part of your automated build process, you may want to familiarize yourself with the development web server that’s included with Visual Studio. Team Build uses it to run automated tests for ASP.net applications. It differs from IIS in some significant ways, like dynamically selecting a port to run on. Note that it’s also possible to switch between IIS and the Developer Web Server in your Web Application Project. Brian Orrell has a concise example of how to unit test ASP.net pages with Team Build.

If you work with Web Site Projects and Web Application Projects you may have noticed that they have different default platforms (“.NET” for Web Site Projects and “Any CPU” for Web Application Projects). Team Build deals with solution configurations which map to distinct configuration and platform for each project within that solution. You’ll want to make sure that the Team Build project file (TFSBuild.proj) is configured to build the “Any CPU” flavor of your configuration. Joel Semeniuk talks more about configurations in his blog post on Automating Web Site Builds with Team Build.

Where do we go from here?

What pain points have you encountered with ASP.net applications and TFS? Let me know either by posting a comment here or by contacting me directly and I’ll do my best to help you find a solution. Of course you can also post your question on the Build Automation MSDN Forum, which my teammates and I visit on a regular basis.

Summary of Links

Team Development with Visual Studio Team Foundation Server – Patterns & Practices
TFS 2008 Branching Guide 2.0 – CodePlex
Using the Tilde (~) in ASP.NET Everywhere – C# Shiznit
VS 2005 Web Project System: What is it and why did we do it? – ScottGu’s Blog
VS 2005 Web Application Project V1.0 Released – ScottGu’s Blog
Introduction to Web Application Projects – Visual Studio 2005 Developer Center
FAQ and Known Issues Web Application Projects – ASP.net Forums
ASP.net 2.0 – Web Site vs. Web Application project – Maor David
Web Application Projects and Web Deployment Projects are here – Rick Strahl’s Web Log
Unleash it – eXcentrics world
Visual Studio 2005 Web Deployment Projects – ASP.net Developer Center
Copy Web Site Feature in Visual Studio 2005 [WMV] – Jim Cheshire
Improvements in Visual Studio 2005 – ASP.net
VS 2008 Web Deployment Project Support Released – ScottGu’s Blog
Using Web Deployment Projects with Visual Studio 2005 – .NET Framework Developer Center
VS 2005 Web Deployment Projects – ScottGu’s Blog
Announcing RTW version of Visual Studio 2008 Web Deployment Projects – Visual Web Developer Team Blog
Team Build and Web Deployment Projects – Aaron Hallberg
Web Deployment Tool – Internet Information Services (IIS.net)
Web Deployment with VS 2010 and IIS – Visual Web Developer Team Blog
Microsoft Web Platform Installer 1.0 – Microsoft.com
How do I: Deploy a Web Application during a Team Build? – Paul Hacker
How To – Structure Your ASP.net Projects for TFS – J.D. Meier, Jason Taylor, Prashant Bansode
How To: Structure ASP.net Applications in Visual Studio Team Foundation Server – J.D. Meier, Prashant Bansode, Alex Mackman, and Kevin Jones
ASP.net MVC Project and TFS Team Build Issue – Hosam Kamel
Unit Test ASP.net Pages with Team Build – Brian Orrell
Tip #20: Did you know… How to change WAP to use an IIS Web server? – Web Developer Tips
Tip #21: Did you know… How to set a fixed port for the Developer Web Server – Web Developer Tips
Tip #24: Did you know… You could display CSS/HTML errors as warnings or errors? – Web Developer Tips
Solution Configurations – Aaron Hallberg
Automating Web Site Builds with Team Build – Joel Semeniuk

Improving Build Performance in TFS 2008

JimLamb — Tue, 10 Feb 2009 15:40:00 GMT

There are a number of things you can do to improve build performance in TFS 2008:

Reduce the scope of the Get as much as possible by fine-tuning the workspace mapping.
Reduce the verbosity of the MSBulid logger (defaults to “diagnostic” in .NET 3.5) by adding the following to your TfsBuild.rsp file: “/flp:verbosity=normal”.
Review these tips on speeding up large builds from Channel9.
Set the IncrementalGet property to True in TFSBuild.proj if you’re OK with re-using sources across builds.
Set the IncrementalBuild property to True if you’re OK with re-using outputs across builds.
Turn on MSBuild multiproc support to get parallelization of solution builds – works best on Build Agents with multi-core processors.
Install SP1 and the TargetsNotLogged Hotfix on your Build Agents to reduce noise in the build logs.
If you’re using a TFS proxy, configure your Build Agent to use it too by following this post (but substituting 9.0 for 8.0):
Consider partitioning the build process into multiple build definitions, e.g. (a) an incremental continuous integration build that just validates the latest changeset without copying a drop, and (b) a clean nightly build that builds that same label as the last good CI build and runs a suite of automated tests.
Schedule disk defragmentation on your build agents – if you do continuous integration and nightly builds, it might be best to schedule defragmentation for the weekend.
Use build machines with fast hard drives – upgrading to a newer, faster hard drive is a relatively cheap way to improve build performance. The performance of WD’s 750 GB 7200 RPM drive is very close to the fastest mechanical hard drives available at less than $100.
Use a Server (not a Workstation) OS to host the drop folders – e.g. Windows Server 2003 rather than XP.

Have any good tips on improving build performance? Please share them by posting a comment here.

Update: William Bartholomew has a two great posts on build performance: Monitoring Build Performance and Drilling into Build Performance – March 19, 2009.

Coming soon – Gated Check-in

JimLamb — Sat, 24 Jan 2009 01:44:00 GMT

This is the first in a series of planned blog posts on new features coming in Team Foundation Build 2010.

Team Foundation Build 2010 includes a new feature that lets you reject check-ins if the associated changes cannot be successfully (and automatically) merged with the current sources and built using a build definition with a new trigger. Changes that do merge and build successfully are committed to the version control repository on behalf of the user who originally submitted the check-in.

Configuring a Build Definition for Gated Check-in

Gated check-in is exposed as a new trigger type in the Build Definition editor. In the same way that you would enable continuous integration, you can enable gated check-in. When you do, be sure to review the workspace mapping associated with the build definition. Any check-in that affects that workspace mapping will be intercepted at the server and shelved (after prompting the user on the client-side for confirmation).

Gated Check-in Data Flow

Caveats, Provisos, etc.

There are some edge cases to be aware of when using gated check-in:

If you have two build definitions with overlapping workspace mappings that are both gated and a user submits a check-in that affects them both, the user will get to pick which one gets built to verify their changes.
If the changes merge and build successfully, they get committed to the repository. This leaves the user’s local workspace in a state where they have pending changes that have actually already been committed. There is an “Update Workspace” command that fixes up their workspace to clear the pending state from those changes but it can create some confusion. It’s also important to note that, due to the automatic merge, the changes that get committed may not be identical to the changes the user submitted.
Builds triggered by gated check-ins are serialized so that only one build of a gated build definition can execute at a time (even within a pool of build resources). This was done to preclude the possibility of conflicting changes getting submitted.

Here’s a somewhat dated, though still informative, video walkthrough of the gated check-in feature:

<\/embed><\/div>";" galleryimg="no" mce_src="http://blogs.msdn.com/blogfiles/jimlamb/WindowsLiveWriter/ComingsoonGatedCheckin_F974/video657f2f64fcdc.jpg">

Building “Classic ASP” applications with TFS 2008

JimLamb — Tue, 13 Jan 2009 20:37:00 GMT

As far as VS 2005 or VS 2008 are concerned, “Classic ASP” applications are just text files. You can edit them and you can check them in and out of version control. When people ask about managing “Classic ASP” applications with VSTS/TFS, they’re usually asking about how they should manage the VB6 components. Here’s what I recommend for VSTS/TFS 2008:

Download and install the latest MSSCCI provider for TFS 2008. This release lets the following clients perform version control operations against TFS: Visual Studio.NET 2003, Visual C++ 6 SP6, Visual Basic 6 SP6, Visual FoxPro 9 SP1, Access 2003 SP2, SQL Server 2005 Management Studio, Sparx Systems Enterprise Architect 6.1, Sybase PowerBuilder 10.5 and Toad for SQL Server 2.0.

Note: If you have an earlier version of the MSSCCI provider installed, be sure to uninstall it before installing this version.
Check the “Classic ASP” application sources into TFS 2008 version control.

Create a TFSBuild.proj file to build the application and check it into version control. You’ll need to create this file manually since the Project File Wizard in Team Explorer only lets you target Visual Studio 2008 solutions and projects. The project file would look something like this:

<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets" />

  <PropertyGroup>
    <VB6>$(ProgramFiles)\Microsoft Visual Studio\VB98\VB6.exe</VB6>
    <VB6Output>$(BinariesRoot)\VB6\</VB6Output>
    <VB6Timeout>150000</VB6Timeout>
  </PropertyGroup>
 
  <ItemGroup>
    <ProjectToBuild Include="$(SolutionRoot)\Source\[ApplicationDirectory]\{application].vbp"/>
  </ItemGroup>
 
  <Target Name="AfterCompile">
 
    <Message Text="CompileProject: %(ProjectToBuild.Identity)"/>
    <MakeDir Directories="$(VB6Output)" Condition="!Exists('$(VB6Output)')"/>
 
    <Exec Condition=" '@(ProjectToBuild)'!='' "
       Command="&quot;$(VB6)&quot; /m &quot;%(ProjectToBuild.Identity)&quot; /outdir &quot;$(VB6Output)&quot; /out &quot;$(VB6Output)VB6.log&quot;"
       Timeout="$(VB6Timeout)"/>
 
  </Target>
</Project>

Thanks to Martin Woodward (Team System MVP) of Teamprise (provider of cross-platform TFS clients) for his suggestions to include the import of the Team Build targets file and to override the AfterCompile target. Of course, you can customize your project file as necessary to meet your requirements. Be sure to check out the MSBuild Extension Pack, Microsoft SDC Tasks, and the MSBuild Community Tasks Project for a number of helpful custom MSBuild tasks.

Create a new build definition and, on the Project File page, browse to the TFSBuild.proj file you just checked into version control.
Queue a build of your newly created build definition and you should have a good build of your VB6 components.

That should put you well on your way towards building a “Classic ASP” application with VSTS/TFS 2008. Please let me know if you have any questions.

Note: I used an Online HTML escape tool to escape the project file snippet and Google Prettify to do the syntax highlighting.

TFS 2008 – HP Quality Center Connector December Pre-release

JimLamb — Wed, 07 Jan 2009 01:40:00 GMT

The TFS product team has been working with Hewlett Packard’s (HP) Quality Center team to develop the TFS 2008 – HP Quality Center (QC) Connector. It lets Quality Center 9.2 users synchronize their Defects with Work Items in TFS 2008. This synchronization can be performed interactively with a Windows (GUI) application or as a background task (running as a service). The Connector is built on the TFS Synchronization Toolkit and is available for download from Microsoft Connect (registration with the Connect site is required).

Along with the installer for the QC Connector, we’ve included a Getting Started (registration required) guide that explains the prerequisites, installation, configuration and usage of the Connector. There’s also a ZIP file containing a sample XML configuration file and a custom process template designed to sync with the demo project included with Quality Center 9.2. The sample configuration file and process template illustrate the following features of the Connector:

Synchronize Quality Center 9.2 Defects with TFS 2008 Bugs
Map enumerated values (e.g. priority, severity)
Map aliases in QC to display names in TFS and vice versa
Synchronize attachments
Synchronize links to other defects/bugs
Synchronize HTML fields in QC with HTML fields in TFS

The Connector itself is free. It does, however, require a TFS CAL and a QC CAL for the machine it's running on. In addition, everyone who views/edits data that's stored in TFS will need a TFS CAL.

This is the second pre-release with the next one (due later this month) planned as the formal Beta release. If you have any questions about the Connector, please contact me.

Integrating Dependencies into Team Build 2010

JimLamb — Mon, 03 Nov 2008 23:40:05 GMT

I was just reading Brad Butt's Suggestions for Microsoft, Part 1 and I thought I'd take the opportunity to let him know that we are addressing two of his three frustrations in Team Build 2010.

Brad's Frustration #1: MSTest cannot stand alone from the Visual Studio IDE

The Team Test team is planning to provide us with a redistributable package that encapsulates MSTest.exe and all of its dependencies. We plan to integrate that into the Build Service installation for Team Build 2010 meaning that you'll be able to run your automated tests on a default build service installation.

Brad's Frustration #2: VSTS Code Coverage only works with MSTest

Unfortunately, I can't help Brad with this one. Hopefully it's somewhat mitigated by what we're doing with frustration #1.

Brad's Frustration #3: MSBuild can't build my MSI

You can work around this limitation by invoking DevEnv on a Visual Deployment (vdproj) project, but I'll admit it's less than ideal. We are, however, integrating the WiX redistributable into the Team Build 2010 installer as well so that you'll be able to build your WiX projects on a default build service installation. You'll still have to port your Deployment Project to WiX which may be a fairly involved process depending on the complexity of your installer.

It's great to get validation from members of the .NET community like Brad that we're on the right track. I just wish we could get these features out to you faster. I do encourage everyone to keep on blogging, posting to the forums, etc. We really are paying attention and doing our best to make VSTS/TFS the very best team software development solution out there.

BizTalk Server and Team Build

JimLamb — Mon, 29 Sep 2008 13:10:51 GMT

We’ve been talking with the BizTalk Server team about supporting MSBuild (and, transitively, Team Build) in their next release but I thought I’d share a really terrific post I recently came across about building BizTalk Server projects with the current version of Team Build.

Mikael Håkansson has authored a two-part blog post on Using Team Foundation Build for BizTalk projects (Part 2). There’s no “one size fits all” solution to these sorts of problems, but Mikael has put together a pretty sophisticated solution to meet his needs that includes a set of custom tasks (downloadable from his blog). If it doesn’t meet your specific requirements, it will certainly give you a head start.

If you’re looking for a simpler solution to the problem, Scott Colestock has a nice write-up on building BizTalk solutions with Team Build that involves using an Exec task to launch DevEnv.exe on the solution with your BizTalk project. Alternatively, you can use Aaron Hallberg’s excellent DevEnv Task.

Project System Compatibility with Team Build

JimLamb — Mon, 29 Sep 2008 12:49:46 GMT

There are a number of projects that you can create and build in Visual Studio that are not supported by MSBuild. That means you can’t use MSBuild to build them from a command line and you can’t build them if they’re contained in a solution you’re building with Team Build. These project types include:

SQL Server Reporting Services (SSRS) Projects
SQL Server Integration Services (SSIS) Projects
SQL Server Analysis Services (SSAS) Projects
BizTalk Server Projects
Setup (Visual Deployment) Projects
SharePoint Server Projects

I previously posted about Jim Morris’ solution for building SSIS packages with Team Build and I’ll be posting more information in the near future on the other project types that aren’t directly compatible with Team Build. If there’s a particular project type that you’re having trouble getting to build with Team Build, please let me know.

SQL Server Integration Services and Team Build

JimLamb — Wed, 30 Jul 2008 00:27:40 GMT

I recently came across a helpful post on Jim Morris' IDeveloper blog. He describes how to get your SSIS packages "building" in MSBuild (allowing them to be built by Team Build as well).

The problem stems from the fact that Team Build uses MSBuild but SSIS projects are not written in MSBuild format. They are just plain old xml. So did you get MSBuild in your SSIS or did you get SSIS in your MSBuild? Not sure why this (and other BI) project type was not written using the MSBuild schema... In the meantime here is a solution to get your SSIS packages "building".

Here's a link to Jim's post:
You got SSIS in my MSBuild

Best Practices for Shared Virtual Machines

JimLamb — Fri, 18 Jul 2008 17:46:07 GMT

I was working with a shared VPC the other day and I thought I'd share some of my thoughts on how to make them a little easier to work with.

Turn off the Shutdown Event Tracker

The Shutdown Event Tracker is a feature in Windows Server that prompts the user to explain why they are shutting down or restarting the server. While this is a useful feature for production servers, it's just annoying for shared virtual machines. If you're not sure what I'm talking about, here's a screen shot of the dialog displayed by the Shutdown Event Tracker:

To prevent Windows Server from display this dialog when someone shuts down the virtual machine, follow the steps below:

Run the Group Policy Object Editor (gpedit.msc)
Navigate to the Local Computer Policy > Computer Configuration > Administrative Templates > System node in the tree control on the left and double click the "Display Shutdown Event Tracker" item on the right.
Click the "Disabled" radio button to disable the Shutdown Event Tracker.

Turn on Automatic Logon

Keeping track of logon credentials for shared virtual machines is cumbersome. You generally end up creating a text file with the credentials and placing that text file in the directory with the virtual machines files and hope that they stay together as a set. The easier way to do it is to enable automatic logon in the virtual machine.

Run the Registry Editor (regedt32.exe).
Locate the following key in the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Double-click the DefaultUserName entry, type your user name, and then click OK.
Double-click the DefaultPassword entry, type your password, and then click OK. NOTE: If the DefaultPassword value does not exist, it must be added. To add the value, follow these steps:
- On the Edit menu, click New, and then point to String Value.
- Type DefaultPassword, and then press ENTER.
- Double-click DefaultPassword.
- In the Edit String dialog, type your password and then click OK.
  NOTE: If no DefaultPassword string is specified, Windows automatically changes the value of the AutoAdminLogon key from 1 (true) to 0 (false), disabling the AutoAdminLogon feature.
On the Edit menu, click New, and then point to String Value.
Type AutoAdminLogon, and then press ENTER.
Double-click AutoAdminLogon.
In the Edit String dialog box, type 1 and then click OK.
Quit the Registry Editor.

Note: To bypass the AutoAdminLogon process and to log on as a different user, hold down the SHIFT key after you log off or after Windows restarts.

Additional Software

Consider installing some additional software for to make the virtual machine more convenient to use.

BgInfo. How many times have you walked up to a system in your office and needed to click through several diagnostic windows to remind yourself of important aspects of its configuration, such as its name, IP address, or operating system version If you manage multiple computers you probably need BGInfo. It automatically displays relevant information about a Windows computer on the desktop's background, such as the computer name, IP address, service pack version, and more. You can edit any field as well as the font and background colors, and can place it in your startup folder so that it runs every boot, or even configure it to display as the background for the logon screen.

If you have any other suggestions on how to make shared VPCs easier to work with. I'd love to hear them!