Buck Hodges

Visual Studio ALM (VSALM, formerly VSTS) - Team Foundation Service/Server (TFS) - MSDN

July, 2007

Posts
  • Buck Hodges

    TFS 2008: Build agent configuration options

    • 15 Comments

    While some of the build agent properties are available in the VS GUI, buried in the tfsbuildservice.exe.config file are a number of options that control key aspects of the build agent and the build.  This file existed in TFS 2005, but it had fewer options.  While you don't have to change anything for the build agent to work in the normal case, there are options here that will help you get more out of the product.  In future releases, these types of options will be exposed in better ways (e.g., GUI).

    Everything described below applies to TFS 2008 Beta 2 through TFS 2008 RTM.  Many of these settings were also in Beta 1, for those of you that are experimenting with that release (if the setting doesn't appear in the tfsbuildservice.exe.config on your build computer, then it was added after Beta 1).  Some of these features were described earlier but with much less detail.

    Any time you make a change to the tfsbuildservice.exe.config file, you must restart the Visual Studio Team Foundation Build service (from the Windows Start menu, choose Run and execute services.msc, select the service and click Restart).

    Building independent projects simultaneously

    The msbuild included with the .NET Framework version 3.5 has the capability of using multiple processes to build projects in your solution that are independent of one another.  In TFS Build, the default is to continue to use only one process for maximum backwards compatibility.  To make use of this new feature,  you'll want to set the MaxProcesses setting to a different number.  One general rule of thumb is to set it to twice the number of processors or cores in your computer.  Finding the optimum value, though, will require experimentation with your own builds since that depends on the I/O and CPU characteristics of your builds.  Aaron wrote about this recently.

    Running GUI tests as part of your builds

    A Windows service doesn't have access to a desktop, and thus the standard configuration of the build agent cannot run unit tests that involve GUIs.  You can do that, however, if you log onto the build computer as the user account that you want running your builds and simply run tfsbuildservice.exe from a Visual Studio 2008 Command Prompt.  Leave the logon session up, and tfsbuildservice will run indefinitely.  We call this running the build agent "interactively" for lack of a better term.  In the config file below, you will find the InteractivePort setting.  That port number, which defaults to 9192, is used by the interactive build agent.  When you configure the build agent in the Visual Studio GUI, simply change the default port of 9191 in the Build Agent Properties dialog to be 9192 instead.  Now you can run GUI tests as part of your build!

    See How to: Configure an Interactive Port for Team Foundation Build for the steps.

    Requiring an authenticated user connection to the build agent

    In TFS 2005, the communication between the TFS application tier (AT) and the build agent used .NET Remoting.  With the advent of Windows Communication Foundation (WCF) in .NET Framework version 3.0, we were able to change to using SOAP web services like the rest of TFS without requiring that IIS be installed on the build agent.  In TFS 2008, we default to requiring that every connection to the build agent is authenticated via NTLM, which is the AuthenticationScheme setting.  However, it could still be any valid Windows account.  To further secure your build agent, you can now also specify the service account under which that TFS AT is running as the only user allowed to connect to the build agent.  That setting is the AuthorizedUser.

    Using HTTPS, possibly with X.509 certificates

    TFS 2008 supports X.509 certificates.  As part of that work, we added the capability to use HTTPS to secure the web service communication channel between the application tier and the build agent.  To require that HTTPS be used to connect to the build agent, simply set the RequireSecureChannel setting to true.  You will also need to set the checkbox in the Build Agent Properties dialog for the build agent in Visual Studio (Build -> Manage Build Agents, then choose Edit to modify an existing agent or New to create a new one).  Additionally, you can require that the communication to the build agent use X.509 certificates by setting RequireClientCertificate to true.

    Extranet support

    We've still got a ways to go to provide true extranet or internet support, but we've made some improvements in this area.  When the TFS AT calls the build agent, it sends the build agent its URL.  That URL comes from the AT's web.config file.  It's value is set when the TFS AT was installed.  It typically uses the short name of the server.  For example, it's typically http://mytfsserver:8080 rather than http://mytfsserver.somedomain.corp.company.com:8080.  If your build agent needs to contact that server using either that fully qualified domain domain (FQDN) or perhaps an entirely alternate name, such as http://secretserver.extranet.company.com:7070, you can set the ServerAccessUrl setting to be that other URL.  The AllowedTeamServer setting must still match the URL sent by the AT, so it would typically hold the short form.

    The AllowedTeamServer setting exists also in TFS 2005, but you've likely never seen or even heard of it unless you need to change which TFS AT the build agent will listen to.  That's because that when that key is not set, the URL of the first AT that successfully communicates with the build agent is stored in the registry (HKCU for the account under which the build agent is running).  Its role and behavior has not changed in TFS 2008.

    At the risk of getting lost in minutia, I want to explain one more related aspect.  Feel free to skip this part if it's not clear.  To determine whether the AT that is connecting to the build agent is the correct (allowed) server, the build agent will compare the value in AllowedTeamServer or the HKCU registry (.config file setting has precedence) to the server URL sent by the AT.  If the two match, it continues processing the request.  If they do not match, the build agent tries to determine if it's really the right AT but with a different name.  To do that, it requests the GUID from both the server specified by the URL that was sent with the request and the server specified by its configured server URL.  If the two match, it continues.  If they don't, it will reject the request.  In TFS 2005, the build agent would call the domain name server (DNS) to get the IP addresses to do the comparison.  The change to using each server's GUID is an incremental improvement that will help folks who've had problems with this in the past.

    Oh, and don't forget that if your build agent is separated from you TFS AT via a low-bandwidth connection, you can set the build agent to use the version control proxy.

    Possible support for future versions of msbuild

    While we don't know what the future of msbuild holds, we do know that the TFS 2005 build agent cannot run the new msbuild in .NET Framework 3.5 because the code gets the CLR runtime directory to determine the location of msbuild.exe.  Those who've paid close attention to the difference between the CLR and the framework will know that the CLR version in Visual Studio 2008 remains 2.0, while the framework is obviously 3.5.  The result is that the TFS 2005 build agent will only execute the 2.0 version of msbuild.  To attempt to be a bit more future proof (no guarantees, of course), we've included a setting that allows you to specify the path to msbuild.exe.  This means that if the .NET Framework 4.0, for example, contains a new version of msbuild (3.0, by the way, did not), you would be able to specify the path in the MSBuildPath setting to have the TFS 2008 build agent use it.  There's no way to know for sure at this point whether it would work, of course, but at least you'll have the option.

    Separate log files per project

    Have you ever wanted to have a separate build log file per project?  Well, we know some of you do, because it's come up on the MSDN Build Automation forum a number of times.  If you set LogFilePerProject to true, you will get that.

    Better support for source files with really long paths

    A number of users ran into problems in the TFS 2005 build agent where they had trouble building their applications because the paths to the source files were really long.  The TFS 2005 build agent would create a build directory path that consisted of the build directory set via the GUI dialog or the tfsbuild.proj file, the team project name, the build type name, and then the word "Sources."  The result was that users were left with substantially less than the Window's path limit of 260 characters to work with (yes, Windows supports 32K character paths, but .NET doesn't).

    In TFS 2008, you have options to deal with this.  Aaron provides the details here.  The short version is that you can set the root of the build directory in the Build Agent Properties dialog.  If it's still not short enough, you can use the SourcesSubdirectory setting to shorten the word "Sources" to "s" if you want.  So you can end up with something as short as C:\b\s, if you need.

    Conclusion

    We've provided a number of new options for the build agent in TFS 2008.  While it's far from ideal that you need to edit a .config file and restart the Windows service for the changes to take effect, we've at least gotten support in there to address some of these issues.  In future releases, we'll be working to make these and other options easier to work with.

    I've copied the contents of %ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\tfsbuildservice.exe.config below for reference (minus the tracing information at the top of the file).  As you can see, we tried to document the settings to make it easier to know how to change them.  Hopefully, there's enough here to get you going.

    <?xml version="1.0" encoding="utf-8" ?>
    <configuration> 
    <appSettings>
    <!-- port
    This is the port that is used by the Team Foundation Server
    Application Tier to connect to agents hosted by this executable
    when it is run as a windows service. This value has to be the 
    same as the value specified for the agent(s) in the Application 
    Tier.
    -->
    <add key="port" value="9191" /> 
    <!-- InteractivePort
    This is the port that is used by the Team Foundation Server
    Application Tier to connect to agents hosted by this executable
    when it is run as a command-line application. This value has to
    be the same as the value specified for the agent(s) in the 
    Application Tier.
    -->
    <add key="InteractivePort" value="9192" /> 
    <!-- AuthenticationScheme
    This string controls what type of authentication will be accepted for
    incoming connections. The following values are supported:
    Anonymous, Digest, Negotiate, Ntlm
    When specifying Negotiate, the Build Service Account must satisfy one
    of the following conditions in order for Kerberos authentication to
    work:
    - If on a workgroup, it must be NT AUTHORITY\Local Service
    - If on a domain, it must be NT AUTHORITY\Network Service or the account must have a valid SPN
    The Basic authentication scheme is not supported.
    -->
    <add key="AuthenticationScheme" value="Ntlm" /> 
    <!-- AuthorizedUser
    This key provides a mechanism to restrict all access to the agent service
    to a single account. If this value is set then a transport authentication
    scheme of Basic, Digest, Negotiate, or Ntlm must be used.
    -->
    <add key="AuthorizedUser" value="" />
    <!-- RequireSecureChannel
    This boolean value controls whether or not transport-layer security 
    should be used for the exposed service. Normally, HTTP is used for
    communications which may not be desirable for a machine exposed on
    the internet. Set this value to true to expose the service using
    HTTPS instead. This value has to be the same as the value specified 
    for the agent(s) in the Application Tier.
    -->
    <add key="RequireSecureChannel" value="false" />
    <!-- RequireClientCertificate
    This boolean controls whether or not a client certificate should be
    required when using a secure channel.
    -->
    <add key="RequireClientCertificate" value="false" />
    <!-- AllowedTeamServer
    This is the Team Foundation Server Application Tier that can connect
    to this build machine. This value should be the URL for the AT,
    such as http://myserver:8080>.
    This value overrides the setting in HKCU.
    -->
    <
    add key="AllowedTeamServer" value="" />
    <!-- ServerAccessUrl
    This only needs to be set when the URL required to communicate to
    the Team Foundation Server Application Tier (AT) is different than the
    one specified in AllowedTeamServer.
    The most common case would be when the AT and the build
    agent are separated by the internet. For example, AllowedTeamServer
    may need to be <http://myserver:8080>, but the build agent may need to use
    http://boundaryserver.corp.company.com:80> to connect to the AT.
    -->
    <add key="ServerAccessUrl" value="" />
    <!-- BuildOnFatPartitions
    As a part of the build process, access controls are set on the build
    directory to secure it against unauthorized access. By default, only
    NTFS partitions are allowed as FAT partitions do not support access
    controls. To override this and allow building on FAT partitions set 
    this value to true.
    -->
    <add key="BuildOnFatPartitions" value="false" />
    <!-- DoNotDownloadBuildType
    Set this flag to true if you want to use the build type definition
    existing on the local machine instead of downloading the definition
    from the server. The local path used will be the same as the location
    where the build type would have been downloaded.
    -->
    <add key="DoNotDownloadBuildType" value="false" />
    <!-- MSBuildPath
    Set this value to the full path to the directory of MSBuild.exe to use
    a location other than the default. This should only be needed if a new
    version of the .NET Framework is installed.
    -->
    <add key="MSBuildPath" value="" />
    <!-- MaxProcesses
    Set this value to the maximum number of processes MSBuild.exe should
    use for builds started by agents hosted by this executable.
    -->
    <add key="MaxProcesses" value="1" />
    <!-- LogFilePerProject
    Set this value to true if you would like Team Build to generate errors
    and warning log files for each project, rather than just for each platform
    configuration combination.
    -->
    <add key="LogFilePerProject" value="false" />
    <!-- SourcesSubdirectory
    Set this value to the desired sources subdirectory for the build agents
    hosted by this executable. 
    -->
    <add key="SourcesSubdirectory" value="Sources" />
    <!-- BinariesSubdirectory
    Set this value to the desired binaries subdirectory for the build agents
    hosted by this executable.
    -->
    <add key="BinariesSubdirectory" value="Binaries" />
    <!-- TestResultsSubdirectory
    Set this value to the desired test results subdirectory for the build agents
    hosted by this executable.
    -->
    <add key="TestResultsSubdirectory" value="TestResults" />
    </appSettings>
    </configuration>

    [UPDATE 9/07/07] I've added a link to the official doc for changing the port.

  • Buck Hodges

    TFS 2008: How to check in without triggering a build when using continuous integration

    • 29 Comments

    If part of your build process is to check in a file, such as an updated version file, you wouldn't want that checkin to kick off another build.  You'd be stuck in an infinite loop.

    To prevent that problem, simply put the string ***NO_CI*** in the checkin comment.  The code that examines a changeset to determine whether to kick off a new build will skip any changeset with that string in the comment.

    [Update 07/02/2008]  If you are making a checkin as part of the build process, you can use $(NoCICheckinComment).  That property is set at run time when the build agent starts msbuild.  I had forgotten about it until a reader pointed this out.

  • Buck Hodges

    Keyword expansion in TFS

    • 63 Comments

    Periodically, the topic of keyword expansion comes up, which TFS (at least through 2008) does not support.  At one point during the v1 product cycle, it was a planned feature and was partially implemented.  However, there are lots of challenges to getting it right in TFS version control, and it wasn't worth the cost to finish the feature.  As a result, we ripped it out, and TFS does not support keyword expansion.

    Since it's not supported in the product and not likely to be supported any time soon, folks gravitate toward the idea of using checkin policies to implement keyword expansion.  The idea is appealing since the checkin policy will be called prior to checkin, of course, which would seem to provide the perfect opportunity to do keyword expansion.

    Personally, I’m not fond of trying to do keyword expansion as a checkin policy.  There are a number of issues related to checkin policies to deal with immediately, because any checkin policy that performs keyword expansion is going to modify file contents.

    • Checkin policies get called repeatedly.  Every time the user clicks on the checkin policy channel in the pending changes tool window in Visual Studio, for instance, the checkin policies are evaluated.
    • Whatever a policy does must be done really quickly.  Otherwise, you are going to make the VS painful to use.  The checkin policy evaluation isn't done on a background thread, and it wouldn't really help anyway since you wouldn't want to have to wait for some long policy evaluation before the checkin process started.
    • Checkin policies can be evaluated at any time.  The user may or may not actually be checking in at the point that the checkin policies are evaluated.  You even have the option of evaluating checkin policies prior to shelving.
    • For applications using the version control API, checkin policies are only evaluated if the application chooses to evaluate them (see How to validate check-in policies, evaluate check-in notes, and check for conflicts).  Some folks may read this and this it's a hole in checkin policy enforcement.  However, since checkin policy evaluation is done on the client, you can't rely on it being done (i.e., clients can lie and call the web service directly anyway).  The other reason has to do with performance.  For an application like Visual Studio, it controls when checkin policies are evaluated, and by the time that it calls the version control API to checkin, there's no need to evaluate them yet again.  Some day there may be server-side checkins, but they don't exist yet (as of TFS 2008).
    • You've got to get your checkin policy onto all of the client computers that are used to check in.  The deployment story for checkin policies is probably the single biggest hole in the checkin policy feature in the product (the second biggest hole is the lack of built-in support for scoping the policy to something less than an entire team project, though there is a power tool checkin wrapper policy to do that now).  Any computer without the checkin policy assembly on it and properly listed in the registry is not going to do keyword expansion.

    If you read that and still want to do it, you would need to pend an edit on each file that does not already have the edit bit set (for example, non-edit branch, merge, rename, and undelete) and is not a delete (can’t edit a pending delete).  I’m pretty sure that VS and the command line will have problems with changes being pended during a checkin policy evaluation, because they’ve already queried for the pending changes and won’t re-query after the pending checkin policy evaluation.  This would result in edits not being uploaded.  This pretty much makes pending edits on files via the checkin policy impractical.

    Alternatively, you could do keyword expansion only for changes where the edit bit is already set in the pending change.  That's sort of the "least evil solution."  You would just use the checkin policy for keyword expansion in files that already have pending edits (i.e., check to see that the Edit bit is set in the pending change’s ChangeType).

    Some of the files with pending edits may not have actually been changed (e.g., you pended edits on all of the files in a directory as a convenience because you knew you would be editing at least half of them via a script).  When the server detects that a file that's being checked in with only a pending edit hasn't been modified, it doesn't commit a change for that file (i.e., create a new version of that file).  You can read a bit about that in the post, VC API: CheckIn() may return 0.  To detect for yourself whether this is the case, you can compute the MD5 hash of the file content and compare that to the HashValue property of the PendingChange class.  If the two are equal, then the file didn't change.  For those of you doing government work, you'll want to watch out for FIPS enforcement.  When that's turned on in Windows, MD5 hashes are unavailable because the MD5CryptoServiceProvider class in .NET throws when you try to create one.  In that environment, the hash values are empty arrays.

    But wait, there's more!  You would also have to make sure that you read and write the file in the correct encoding (e.g., reading in DBCS as ASCII or Unicode would be bad – for example, Japanese or Chinese DBCS files).  There are probably more encoding issues to contend with.  One thing that's probably on your side, though, is that if you do read in the file in the wrong encoding, you won't likely find the markers indicating that the file needs keyword expansion.  To avoid randomly finding the tags when you know you don't want to, you'd likely want to skip all binary files that your expansion logic doesn't know how to handle (e.g., you could conceivably handle keyword expansion in JPEG file headers, but that doesn't seem too likely).

    The other thing to consider is how keyword expansion interacts with branching and merging.  Imagine putting the date in every file in a keyword expansion system.  It’s going to be a merge conflict every time your merge branches.  The same is true for log (history) information.  You would need to write a tool to handle the content conflicts; otherwise, merging large branches would be a real bear.

    Even with all of that, you are not going to get one of the things that often comes up (and this was true when we were thinking of putting in the product, because it was all going to be done on the client prior to checking in) which is the ability to record the changeset number in the keyword expansion comment.

    So, to sum it all up, you are going to need to consider the following.

    1. Your checkin policy will get evaluated multiple times and often not when someone is actually checking in.
    2. You'll want to only modify the files that already have pending edits, as pending new changes from within a checkin policy may lead to new content changes being uploaded with the rest of the checkin.
    3. You'll want to test out how it's going to interact when merging files from one branch to another.  What's it like to deal with the conflicts your keyword expansion introduces?
    4. There will be checkins where keyword doesn't happen for whatever reason, so it's not completely reliable.  This is in addition to the fact that changes that do not already involve an edit won't have keyword expansion at all.

    If we had done keyword expansion as a feature, what would have been different (other than the fact that you wouldn't have to think about all of this :-) )?  We wouldn't have the limitation of 1.  Just like in 2, we'd have to think hard about whether every rename, branch, undelete, and merge should have an edit pended also.  At best it would have been an option, and it wouldn't have been the default.  Regarding the branch merging issue, doing something on the server would be a performance hit that may be excessive with large branches (keep in mind that the server stores the content as compressed and doesn't uncompress it -- the client takes care of compressing and decompressing content), so the client would need to have some logic to help make it bearable (e.g., before performing a three-way merge, collapse all of the expanded keywords).

    Our conclusion was that the feature was too expensive to implement and test relative to the value provided and other features could be implemented and tested with a similar effort (e.g., making history better).  Folks either strongly agree (can't live without it) or disagree (don't care about it at all) with that conclusion.  There's rarely anyone on the fence.  The feedback we've received to this point indicates that we've made the right tradeoff for the vast majority of our customers (and potential customers).

  • Buck Hodges

    Team Foundation Server 2008 Beta 2: Summary of links to Team Build information

    • 14 Comments

    Visual Studio 2008 Beta 2, including Team Foundation Server 2008, is now available for download.  As mentioned in Soma's post, Beta 2, unlike beta 1, includes the "go live" provision in the license, meaning that you can use it in production.  We've been using TFS 2008 beta 2 on our main internal dogfood server now for the last two months (well, it's close to being the same as beta 2 -- it's actually an very early snapshot).  You can check out the stats in Brian's post.

    When Beta 1 was released, I put together a list of links about the Team Build features in Orcas.  If you are looking for a list of links related to TFS 2005, you can find those here (and Jeff has posted links to the TechEd 2007 presentations).

    Here's my updated list of links about Team Build features in TFS 2008 (check out Brian's post for a list of all TFS 2008 features).  If you have questions or feedback about anything in beta 2, please let us know (either here or in the forum).  We're anxious to hear what you think!

    Overview of features in Build for TFS 2008

    Demos

    Vista Sidebar Gadgets to monitor builds (we're working on an equivlaent to CCTray)

    Details on how things work, customizations, etc.

    Object Model API

    Using the API via PowerShell

  • Buck Hodges

    Team Build Compatibility between 2005 and 2008

    • 10 Comments

    The following question came up today, and I thought it would be useful to post.

    One thing I didn't mention was what happens in the upgrade process when you move from a 2005 server to a 2008 server.  The 2008 server stores in the database some properties that were previously stored either in the tfsbuild.proj (build agent computer, build directory) and workspacemapping.xml (build workspace template).  As part of the upgrade process, we read those files and create build definitions for each tfsbuild.proj, build agents with the computer and build directory specified, and workspace templates on the build definitions for each workspacemapping.xml file.

    Also, as Brian mentions in his post today about upgrading to TFS 2008 Beta 2, you will need to install the TFS 2008 build agent on the build computers.  The version of the build agent must match the server due to the changes that we've made.  You can install both on the same machine, but you'd need to change one to work on a different port (that's easier with 2008 than 2005).

    Question

    I know there is high compatibility between 2005 and 2008 with Team Explorer and TFS.  But there are big changes in Team Build.  What will someone see in 2005 Team Explorer when looking into Team Build on a 2008 TFS/Build Server?  Can I actually kick off a 2008 build from a 2005 client?  Can I review build history?  Anything else I should be aware of?

    My answer

    Using the 2005 client with a 2008 server, they will see things just the way they always have, and that means that they won’t see the build queue, build agents, etc.  They will need to use a 2008 client to edit the workspace mappings for a build, as the workspacemapping.xml file used in 2005 is no longer used.  To change the properties of a build agent, they’ll need to use the 2008 client.  Changing the build machine or build directory specified in the tfsbuild.proj file will have no effect because those properties are stored in the database in 2008.

    They cannot queue builds from 2005, since it didn’t have any notion of a queue, but they can start builds from 2005 if the build will start immediately, just as it was in 2005.

    If someone configures a build definition for continuous integration, it will work just fine with either 2005 or 2008 clients, because the CI intelligence is all in the server.

    The 2005 client will show you the list of completed builds.

    We’ve had internal teams that continued to use the 2005 client with the 2008 dogfood server, and they were successful with it.  The thing I would suggest is that at least one person on the team installs Team Explorer 2008 (it works side by side with 2005) so that person can change the settings that are not accessible from 2005.  With the internal teams, diagnosing issues with the build agent, such as account password expiration causing the agent service to stop working, was the part that was confusing because you can’t see the build agent in the 2005 TE.

    The guidance on compatibility from Brian’s April post on the TFS roadmap provides the overall picture and describes the reverse situation (2008 client, 2005 server).

    As Orcas is an adoption focused release, we have put a lot of emphasis on compatibility with VS2005.  We are striving for near 100% compatibility.  The Orcas client will be able to work with a VS2005 server and a VS2005 client will be able to work with an Orcas server.  There are only a few compatibility issues.

    · Client side VS add-ins will need to be recompiled (or have policy changed) because the TFS OM assembly versions will change and add-ins will need to bind to the new assemblies.  The APIs themselves are generally not changing, so we don’t expect much in the way of code changes – just recompilation.

    · Build is the only area where we plan to have some compatibility disconnects.  In general, most build operations - listing build definitions, starting and stopping builds, examining build reports, etc. will work both with 2005 client -> Orcas server and Orcas client -> 2005 server.  However, here are a few caveats:

    1. An Orcas TFS server will only work with an Orcas build server - so you'll need to upgrade your build server when you upgrade your TFS server.

    2. For an VS2005 client to start a build on an Orcas server, the build definition needs to be stored at $/<TeamProject>/TeamBuildTypes/<name>.  In Orcas, you have more flexibility as to where to put them.

    3. Changes made to properties in the .proj file that are in the database in Orcas will not be updated in the database and will no longer be in sync.

    4. VS2005 will be able to start a build, but it can’t queue a build, see the list of builds in the queue, see the list of build agents, etc.

    5. An Orcas client will not be able to create a new build definition on a TFS2005 server.

    6. When starting a build, an Orcas client will not be able to change any parameters in the dialog for a TFS2005 Server.

  • Buck Hodges

    TFS 2008: Some properties that you can use to customize your build

    • 5 Comments

    Martin Woodward has posted a nice list of properties from Team Build that he has found useful.  While some of the properties were also in TFS 2005, quite a few are new for TFS 2008 (aka Orcas).

    Some of the properties, such as RequestedFor, are properties of the current build that are set by the server, and thus you wouldn't set them yourself.

    There are two in particular that I would like to highlight:  IncrementalGet and IncrementalBuild.  Setting IncrementalGet to true in your tfsbuild.proj file (it's false by default for backwards compatibility) will result in each build of that build definition reusing the existing workspace (and it will create a workspace if this is the very first build of that definition) and simply getting the files that have changed since the last build.  By contrast, the default setting will result in every file in the workspace being retrieved each time the build is executed.

    IncrementalBuild takes it one step further.  In addition to doing what IncrementalGet does, it does not clean the binaries output directory.  The result is that each build will simply build binaries corresponding to the source that's changed (assuming you've got all your dependencies setup correctly, etc.).

    Check out Martin's post for more properties. 

    30 Useful Team Build Properties

    If you are going to get into the Zen of TFS Team Build, then at some point you are going to have to read the TeamBuild .targets file (located in %ProgramFiles%\MSBuild\Microsoft\VisualStudio\TeamBuild\Microsoft.TeamFoundation.Build.targets).  The TeamBuild build scripts are usually extensions of this master build script.  In Orcas the script has has several revisions to make sure as many hooks are provided as possible, but extraordinary lengths have been gone to to make sure that scripts written to target the old (VS 2005) version of the file will still work with the new one.   The problem with all MSBuild scripts, and a problem that is shared with Nant and Ant scripts alike, is that they take a little bit of working out.  You cannot just pick up a script and read it from beginning to end due to the way that dependencies work in these process execution languages and the fact that you can have multiple entry points.  Fortunately, the TeamBuild .targets file is very well commented and there is also additional documentation available on MSDN listing the points you should start to look when hooking in your logic.

    However, when you eventually override your first target to write a custom bit of code in the build process, you are going to need to know some properties that are available for you.  Below is my list of 30 build properties that you will find useful.  There are over 70 available if you read the target file you will find them all, these are just the ones that I find most useful - some to read the properties available, and some to override to easily alter the behavior of the build script.

    more...

  • Buck Hodges

    How to build projects in Team Build that only Visual Studio can build

    • 9 Comments

    Aaron has written a great post on using Visual Studio (devenv) from within Team Build as part of the build process.  If that sounds strange, it's necessary because there are projects that Visual Studio can build, but msbuild cannot.  Projects in this category include Visual Studio setup projects (.vdproj), SQL Reporting Services (SRS), and BizTalk.  Some projects may never be supported outside of msbuild, as is the case with the setup projects (WiX works msbuild, if you want a setup technology that doesn't rely on Visual Studio).

    We have documentation, such as this walkthrough on building setup projects, showing you how to run devenv by using the Exec task in msbuild, but this approach has shortcomings.  You don't get any details in the build report.  The syntax is confusing to read with all of the quotation marks, some of which must be escaped.  But the most subtle aspect, and Aaron discovered this in the course of writing is his post, devenv rebuilds the whole solution to another directory, resulting in a different set of binaries being packaged in your setup output.

    To address this, he has written a custom msbuild task that wraps devenv.  In the post he shows you how to use it, and for those who are interested, he describes how it works.  Both the compiled assembly and the source code are attached to the post.  Note that this task only works for TFS 2008 (Orcas) and not TFS 2005 (v1).

    Team Build DevEnv Task

    Because many Visual Studio project types are not supported in MSBuild, many Team Build users end up needing to invoke DevEnv directly.  There is a fair amount of confusion about how to do this best / simplest - I've written two posts (here and here) on the issue already! 

    As such, I thought it would be helpful to write a DevEnv task that could be used to invoke DevEnv from MSBuild during the course of a Team Build build, along with some guidance on how to use it best.  I'll go through how to use the attached DLL for those who just want to use the task, go into a few chunks of the source code for those interested in how the task works, and then go through an example of how to use the task to build a setup project (*.vdproj).  A note for the lawyers: I can make no guarantees as to the awesomeness of this task or lack thereof - it is provided "as is" with no warranties and confers no rights. 

    more...

    While this task isn't going to be part of Orcas (TFS 2008), we'll add it to the TFS power tools once we get some feedback.

    Enjoy and let us know what you think!

    tags: , , , , , , , ,

  • Buck Hodges

    How to enable code coverage without a test list

    • 4 Comments

    Aaron pointed out this post by Ben Day that talks about using the RunConfigFile property with a build that runs tests without using test lists (.vsmdi files).  It all boils down to looking like the following (in Orcas, you would specify the $(OutDir) part in the TestContainer's Include attribute, whereas you don't in the TFS 2005 power tools TestToolsTask TestContainerInOutput element).

      <ItemGroup>

        <TestContainer Include="$(OutDir)\HelloWorldTest.dll" />

      </ItemGroup>

      <PropertyGroup>

        <RunConfigFile>$(SolutionRoot)\CSharp\Tests\localtestrun.testrunconfig</RunConfigFile>

      </PropertyGroup>

    Read Ben Day's post, Run tests from your TFS Team Build without a test list (.vsmdi) with code coverage, for the details on setting this up with the TFS 2005 power tools task.

  • Buck Hodges

    Get: Date and time, read/write vs. read only

    • 14 Comments

    Periodically we get the following questions about get.

    1. Is there any way to have get set the date and time on a retrieved file to be the last modified date and time from the version control repository rather than the time when it was downloaded?
    2. Is there any way to have get mark files as read/write rather than read only?

    The answer to each is no for both TFS 2005 (v1) and TFS 2008 (Orcas).  It's something we considered doing in v1, but we ended up cutting it.  It remains on the list of features to consider for the future.

    If you have opinions on this or other version control features, you'll want to let Mario know.

  • Buck Hodges

    Goodbye to a 200-year old Osage-orange tree

    • 2 Comments

    This was a 200-year old Osage-orange tree on what used to be part of my grandfather's farm in Charlotte, NC.  This former hay field is now a subdivision (the farm house is directly across the road in the grove of trees in the distance behind the scraper).  The house I grew up in is adjacent to the farm (way over on the opposite side of the farm -- not pictured here).

     

    When I took this picture in August '03, construction was underway to turn the former field into a subdivision.  Precautions were taken during construction to preserve the tree as a centerpiece for the new neighborhood.

    Sadly, the tree was destroyed on the night of July 4, 2007 in a fire started by a firecracker that apparently landed in the hollow trunk of the tree.  After volunteer firefighters tried for eight hours in the middle of the night to put out the fire, the tree was cut down for fear of branches falling out of it.  Some of its branches were large enough to be large trees themselves.

    Over the course of its 200-year life it survived being struck by lightning and who knows what else, but it couldn't survive three years in a subdivision.

    Clicking on the pictures will take you to the page I set up on Flickr.  There's a little bit more information on those pages for the curious.

    Here's the tree in the subdivision. The trunk was measured at 24 feet around after the tree was cut down (that's my uncle Ed on the left).  Note the interesting color of the wood.

    Links to news stories about the fire:

    Technorati tags: , ,
  • Buck Hodges

    New home for the AssemblyInfo task

    • 1 Comments

    The AssemblyInfo task has a new home, because the CodeGallery portion of GoDotNet is being phased out.  You can now find it here in the GotDotNet User Samples.

    The AssemblyInfo task is useful for updating assembly version numbers as part of your build.  Aaron Hallberg explains how to use it with Team Build in his post, Team Build and the AssemblyInfo Task.

  • Buck Hodges

    How to build without having the timestamp change on every file in the build's workspace

    • 23 Comments

    A question came up a couple of times recently about an issue with the timestamps on the files involved in a build always being the current time.  The issue is that folks have customized their deployment process to deploy only files where the timestamps are newer.  Folks then ask for an option to have get set the timestamp to the timestamp when the file was checked rather than when it was downloaded.  I don't think that's the best answer in this case (and if you aren't doing a clean build, it's not an answer at all, since that will lead to botched builds).

    The biggest culprit here is likely that the default behavior for Team Build is to create a new workspace and get all of the files for every build.  We've left that default in place in for TFS 2008, but we may change it in the future.

    You can change Team Build to get only the files that have changed since the last build by having it not create a new workspace each time and doing an incremental get.  Aaron wrote a post about how to do incremental gets in TFS 2005.  It's a simple matter of setting IncrementalGet to true in TFS 2008.

    After making the appropriate change, you'll want to switch to incremental builds if you need to have the binaries updated only when the corresponding source files change (there are links for that in the posts referenced earlier).

  • Buck Hodges

    Orcas: Unattended installation of the build agent

    • 1 Comments

    You can install the build agent (aka Build SKU) without going through the setup UI if you do the following.  Thanks to Tony Edwards for this information.

    Edit the msiproperty.ini.   Note that as of Beta 2, the ones that are in there are bogus and are not used.  You have to add two new ones.  This will be fixed before the release of TFS 2008.

    VSTF_LOCAL_DOMAIN=corpdomain

    VSTF_LOCAL_USERID=someaccount

    If you then run setup silently,

    setup /q

    all of the chained installers get invoked silently and the install succeeds.

    Unattended installation is also supported for Team Explorer.  It's not supported at the moment for the TFS server setup.

    Technorati tags: , , ,
  • Buck Hodges

    Team System Web Access (formerly TeamPlain) power tools release is now available!

    • 1 Comments

    [UPDATE 7/31/2007]  I've updated the link with the main MSDN page for TSWA.  There's also an FAQ now. 

    We have just released Team System Web Access power tool for TFS 2005!  You can download it now.

    Team System Web Access (formerly known as TeamPlain) is a Web interface to Visual Studio 2005 Team Foundation Server.

    Feature Overview

    • Add new work items or edit existing ones
    • Work with any type of work item, including custom ones
    • Add new work item queries or edit existing ones
    • View, download, upload, check-in and check-out documents on SharePoint team portal
    • View reports, export as PDF or Excel
    • Browse source control repositories, download files, view changesets, diffs, histories, and annotated views
    • View build results, start or stop builds
    • Search for keywords in work items
    Authentication Modes
    • Integrated Windows Authentication
    • Forms Based Authentication (Recommended to use with SSL)

    We hope you enjoy this release and let us know what you think!

  • Buck Hodges

    CodePlex project: TFSBuildLab

    • 3 Comments

    Peter Blomqvist and Mathias Olausson have undertaken an ambitious project to provide things like build queuing and continuous integration on top of TFS 2005.  While we have these features in TFS 2008, this project provides some of these essential features for use with your current TFS deployment.

    TFSBuildLab - Project Description

    TFSBuildLab is a project to simplify the day to day operations when using automated builds and Team System.
    This project handles common Team System issues such as:

    - Continuous integration builds
    - Scheduled builds
    - Build queueing
    - Manual and automated build cleanup
    - TFS Event notifications

    Many of these issues are handled in the upcoming TFS release (http://download.microsoft.com/download/5/9/c/59cd0dc5-4691-4c3e-840c-66d865f27692/orcas-continuous-integration.xps), but we wanted to have a good implementation until then and we also aim to be as forward-compatible as possible.

    Project Documentation

    Check it out and give them feedback on it!

    Technorati tags: , ,

  • Buck Hodges

    Survey: Which databases should Visual Studio Team Edition for Database Professionals support?

    • 5 Comments

    Speaking of VSTS for DB Pros, Brian Keller is taking a survey.  If you have an opinion on this, please share it!

    Survey: Which databases should Visual Studio Team Edition for Database Professionals support?

    The team who builds Visual Studio Team Edition for Database Professionals is collecting input on which 3rd-party (non-Microsoft) database providers they should be partnering with for future releases. Microsoft SQL Server 2000 and SQL Server 2005 are the two databases supported in the current release, but the team is investing in infrastructure which would allow partners to build support for non-Microsoft databases as well.

    If you would like to provide your input please take 5-10 minutes to respond to this brief survey:

    http://www.surveymonkey.com/s.aspx?sm=zKzfU_2b_2fBDQqyvECGt88hVQ_3d_3d

    Your feedback is very important and will be used directly by the product planning teams. Even if you don't use Visual Studio Team Edition for Database Professionals today, but you are interested in the functionality it provides for database change management, please consider taking this survey or forwarding it on to a colleague.

    Let Cameron, product unit manager for VSTS for DB Pros, and company know what you think!

  • Buck Hodges

    Adding Team System Web Access to the mix

    • 14 Comments

    A year ago I became the dev lead for Team Build.  As of this month, I'm now also the dev lead for Team System Web Access (TSWA), which is the name of the group that resulted from our earlier acquisition of devBiz Solutions, makers of TeamPlain Web Access.  Hakan, Ahmet, and Serkan have joined our team in North Carolina, relocating from Turkey.  Hakan is the program manager for TSWA, and Ahmet and Serkan are developers on TSWA.  It'll take a while for me to catch up to Ahmet and Serkan. :-)  It's great to have them on the team, and I look forward to this team delivering some great features.

    We'll soon be releasing the power tool version of TSWA for TFS 2005 (the original TeamPlain is still available here).  After that, we'll be working on a similar power tool release for TFS 2008.  Beginning with Rosario, which is the release of TFS following TFS 2008, TSWA will be an integrated part of the product rather than a separate power tool.

    Let us know what you need in TSWA.  We're planning for Rosario now, so it's a great time to give us your feedback.

  • Buck Hodges

    Visual Studio Team System Chat – August 1, 2007

    • 0 Comments

    The next MSDN chat is next Wednesday.  I'm going to try to be on the first one.

    Join members of the Visual Studio Team System product group to discuss features available in Visual Studio Team Foundation Server, Team Editions for Architects, Developers, Database Pros, and Testers.

    There will be two sessions:

    Join the chat on Wednesday, August 1st, 2007 from 10:00am - 11:00am Pacific Time.
    Add to Calendar | Additional Time Zones

    -or-

    Join the chat on Wednesday, August 1st, 2007 from 4:00pm - 5:00pm Pacific Time.
    Add to Calendar | Additional Time Zones

  • Buck Hodges

    MSDN chat with the VSTS (including TFS!) product group is today!

    • 0 Comments

    The first chat is at 1:00 PM Eastern time, so I'm planning to be in that one.

    Join members of the Visual Studio Team System product group to discuss features available in Visual Studio Team Foundation Server, Team Editions for Architects, Developers, Database Pros, and Testers. In addition, discuss what's new in the upcoming Orcas CTP.

    We will be holding two sessions:

    Join the chat on Tuesday, July 3rd , 2007 from 10:00am - 11:00am Pacific Time. Add to Calendar | Additional Time Zones

                    -and-

    Join the chat on Tuesday, July 3rd, 2007 from 4:00pm - 5:00pm Pacific Time. Add to Calendar | Additional Time Zones

  • Buck Hodges

    Why can't I create a Team Project called name.com?

    • 1 Comments

    Recently this question came up on an internal mailing list.  Dennis Habib, a developer on TFS, responded with the following.

    This is because '.com' is a restricted file type. Windows SharePoint Services (WSS) has a list of extensions that it will not accept and will fail (there are quite a few), but there is no way to get this list from WSS programmatically from the client machine so we can't give you a warning (the list is configurable). You need to either remove that name from the restricted list in WSS Central Administration, or choose a different name.

    I didn't know that, so I thought I'd pass it along.  You can find out more at Configuring Blocked File Extensions.

    Technorati tags: , , ,
  • Buck Hodges

    Dave McKinstry on building database projects

    • 1 Comments

    Dave McKinstry has written a three-part series on building database projects.  He includes information on building in TFS Build as well.

    Check it out!

Page 1 of 1 (21 items)