When working with Team Foundation Build, there may be common scenarios that will fall outside the purview of simply creating a basic build task. Here are the three top scenarios and some strategies to implement them.
Team Foundation Build does not support building .NET Framework 1.1 code out of the box. Fortunately, Microsoft has worked on an
MSBee allows developers to build managed applications in Team Foundation Build and Visual Studio 2005 that target the .NET Framework version 1.1. You can download a copy on GotDotNet: gotdotnet.com/codegallery/codegallery.aspx?id=9ac94da5 - 8e5a-4a33-beda-9b8d00970371 .
If you choose not to use the toolkit, you have the following options:
Use devenv .
Override the AfterCompile target.
Use the EXEC task to invoke devenv and build appropriately.
You can learn more about this process by reading the following blog post: http://blogs.msdn.com/nagarajp/archive/2005/10/26/485368.aspx .
To build Visual Basic 6.0 code, Visual Basic 6.0 (the IDE) must be installed on the build server. Use the same EXEC task steps to call the VB compiler that will build the code.
Building ASP.NET applications is nontrivial due to version control and deployment specific challenges. The best thing you can do is to review the following TechNote as a starting point: http://msdn.microsoft.com/vstudio/teamsystem/reference/technotes/team_build/build_asp_proj.aspx .
You may need to debug build errors as a result of building ASP.NET solutions. You can learn debugging tips at h ttp://blogs.msdn.com/nagarajp/archive/2005/10/18/482491.aspx .
Be sure to choose the right platform configuration. If possible use the Visual Studio 2005 Web Deployment Projects at http://msdn.microsoft.com/asp.net/reference/infrastructure/wdp/default.aspx .
Thus far in this chapter, you have learned what Team Foundation Build Server is and how it works. We've overviewed the architecture, explained some of the different
In this last section of the chapter, you are going into a more detail concerning how to set up and manage the Team Foundation Build Server. We talk about managing builds,
In reality, you can manage your builds and your build process any way you want. Team Foundation Build does provide a couple of ways to help you with that management.
We've discussed previously the Team Foundation Build
Figure 3-4 shows a view of the Team Build Browser. To
The Team Build Browser displays Build Name, Build Status, Build Quality, and Completed On date. Notice that each Build Name is the
If you go look in the drop directory for the build, you will see a directory with the same name as the build. This directory contains all the different compiled configurations from the build.
There is a drop-down list at the top of the Team Build Browser, which you can use to determine which builds are shown. The filter options include None, Today, Yesterday, This Week, Last Week, and Last 4 Weeks. You can use this filter to narrow the range of builds you want to look at.
To examine the details of a particular build, you can double-click the build name to open the build report. Once you have examined the build, you should return to the Team Build Browser and change the Build Quality to the appropriate value. That way, other people who examine the build information will know the current state of that build. To do this, simply select the Build Quality column for the appropriate build in the Team Build Browser. The column becomes a drop-down list box, from which you can change the build quality. The default options for Build Quality are Initial Test Passed, Lab Test Passed, Ready For Deployment, Ready for Initial Test, Rejected, Released, UAT Passed, Under Investigation, and Unexamined. In addition, you can easily add your own build quality states, by selecting the Edit option from the Build Quality drop-down list.
You must have the Team Foundation Server Edit build status permission to change the Build Quality.
You can configure Team Foundation Server to notify you via e-mail when different events occur. With regards to Team Foundation Build, you can receive e-
To open the Project Alerts window, open Team Explorer and navigate to the team project you are interested in. Right-click the team project, and select Project Alerts. This opens the Project Alerts window, shown in Figure 3-8:
Using this window, you can specify which events you are interested in receiving notifications for. You enter your e-mail address, and also specify the format: HTML or Text.
When you receive a build notification e-mail, it contains a link to a build detail Web page. You can click this link to view the detailed build information. The e-mail also contains some basic build information, such as the name of the build, when it was started, when it completed, and its quality, as well as links to the build log.
You can have as many build servers in your environment as you would like. Remember, if a build server is going to run tests against the build, then Visual Studio Team Test Edition or Team Suite Edition must be installed on the machine. This means you must have a license for Visual Studio Team Test for each build server you want to run tests on.
When you configure a build type, you specify a build server and a directory on that build server to be used during the build process. You might think, for the same project, you have to create another build type in order to run the build on a different build machine, but that is not the case. Remember, when you start a build from Team Explorer, it opens the Build window, as shown in Figure 3-3. Using this window, you can override the defaults in the build type, and specify a different build machine or build directory. You cannot, however, change the drop location. For that, you do have to create a new build type.
You can do the same thing from the command line, using /machine and /d commands.
The build drop site is where the final build files are deposited, after the build has been completed. In this drop directory is a directory named for each build. Inside each build directory are directories containing the files for each configuration listed in the build type for that particular build.
The drop directory is not automatically shared. Therefore, you need to share the directory out, so that it can be accessed via the UNC ( \\server\share ) location. To create a share, open Windows Explorer on the machine where the build will be dropped. This can be the build machine, or a separate machine just for evaluating built programs. Navigate to the folder where you want to drop the built applications, and right-click the folder name. From the context menu, select Sharing and Security. This opens the property window for the folder to the Sharing tab, shown in Figure 3-9.
Click the Share this folder radio button. Enter the name for the share. Now click the Permissions button to open the Permissions window for the share. Add the service account used to run the Team Build Service, for example, TFSSERVICE, and give them Read and Change permissions on the share. Click OK to save your changes and return back to the properties window for the folder.
Next, click the Security tab in the property window of the folder. Add the service account used to run the Team Build Service, and give it write access. Click the Apply button to apply the changes, and then click OK to close the window. At this point, your drop directory is configured correctly.
As Chapter 4 of this book covers in some detail, and as we have already previously mentioned, Team Foundation Server
The following is a list of all the Team Foundation Server security permissions that apply to Team Foundation Build:
Administer a build - This permission is required to create a new build type, edit an existing build type, or delete an existing build type.
Edit build quality - This permission is required to change the build quality status in the Team Build Browser.
View project-level information - The permission is required to view build reports and to subscribe to e-mail notifications.
Start a build - This permission is required to start, stop, and restart builds.
Write to build operational store -
This permission is required to be able to write the results of builds to the data
Professional Application Lifecycle Management with Visual Studio 2010 (Wrox Programmer to Programmer)
Professional Team Foundation Server 2010 (Wrox Programmer to Programmer)
Professional Scrum with Team Foundation Server 2010 (Wrox Programmer to Programmer)
Inside the Microsoft Build Engine: Using MSBuild and Team Foundation Build