[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 itemsAuthentication Modes Integrated Windows Authentication Forms Based Authentication (Recommended to use with SSL)
Team System Web Access (formerly known as TeamPlain) is a Web interface to Visual Studio 2005 Team Foundation Server.
Feature Overview
We hope you enjoy this release and let us know what you think!
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.
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.
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.
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 Continuous Integration in Team Build for Orcas More on the Orcas features for Team Build You can schedule builds in Orcas Orcas Team Build Continuous Integration spec is now available Demos Eric Lee's Orcas Team Build Screencasts Channel 9 interview and demo of Orcas Team Build Vista Sidebar Gadgets to monitor builds (we're working on an equivlaent to CCTray) Monitoring Build Status in your Windows Vista Sidebar Team Build Monitor – Vista Sidebar Gadget Details on how things work, customizations, etc. Team Build and Web Deployment Projects TFS 2008: Build agent configuration options TFS 2008: Some properties that you can use to customize your build Orcas: Unattended installation of the build agent How to build projects in Team Build that only Visual Studio can build Orcas Team Build: WCF web services replace .NET remoting Building software against different versions of .NET with MSBuild in Orcas Stop piling on when the build breaks: Build checkin policy for Continuous Integration in Orcas Incremental gets with Team Build and the list of files that changed Orcas Changes Determining Whether Tests Passed in Team Build Orcas Getting the Modified Files for a Team Build Build in Orcas Team Build and Web Deployment Projects Team Build and 260+ Character Paths Preserving Output Directory Structures in Orcas Team Build TfsBuild.rsp and Logging Verbosity in Orcas Adding Build Steps to Team Build in Orcas Build Type BuildDirectoryPath => Build Agent Working Directory Getting the Builds Associated with a Changeset Number Object Model API Orcas Object Model Documentation Team Build Object Model - Queueing a Build Using the new TFS Build object model in ORCAS Stop piling on when the build breaks: Build checkin policy for Continuous Integration in Orcas Adding Build Steps to Team Build in Orcas (shows the code used by the built-in task) Using the API via PowerShell Team Build OM thru PowerShell - Example GetAffectedBuildDefinitions Queuing a build in PowerShell Average Build Size Various PowerShell scripts Getting the Builds Associated with a Changeset Number
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
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.
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).
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
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...
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...
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 Installation Quickstart User's Guide
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!
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>
<?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.
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.
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!
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!
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.
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...
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.
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: tfs, team foundation, team build, orcas, tfs 2008, msbuild, devenv, setup projects, vdproj
Periodically we get the following questions about get.
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.
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.
Links to news stories about the fire:
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
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.
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.
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.
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).
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>
<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.
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.
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