•
•
•
•
Etienne Tremblay, a Microsoft MVP, put up a nice Visio diagram showing the ports used by Team Build and the direction that must be opened for each. Check it out!
So we learn stuff everyday... well I hope. Here is a bit of insight on Team Build, specifically the ports that need to be opened for it to work properly in a multi-machine scenario.
tags: tfs, team foundation server, team build
Neno Loje, a Microsoft MVP, posted a nice list of knowledge base articles for Team Foundation. Here's the list (copied from his post).
So I thought I'd try searching the KB to see how easy it is to get this list. Well, I don't like the search interface. If I search by product for Visual Studio Team Foundation Server (the only product name choice), I get the following results (click here to run the query).
Needless to say, that's not a great result.
If instead you search for the phrase "team foundation" you get all sorts of results (79 total, currently), some of which don't seem to be directly related to Team Foundation. Click here to run that query.
Neno's list is much better.
tags: tfs, team foundation server
Brian Keller has put up a video on Channel 9 that has Erin Geaney, a developer on the TFS MS Office integration team, demonstrating the Team Foundation Power Toys that we updated recently. The original release of the power toys was nearly a year ago and was the work of an intern who worked for me, Philip Kelley (he also wrote a paper on how to create shadow folders). The latest power toys release has Visual Studio add-ins, VSS-style project differencing (also written by a summer intern, Taylor Lafrinere), work item tracking commands in tfpt.exe, and more.
tags: tfs, team foundation server
Naren Datha<, a dev who works on the WIT client, has written a post on how to use the new work item tracking custom controls that are introduced in SP1 beta (he previously mentioned some ideas for custom controls). He provides an overview, details on how to create custom controls, some hints for troubleshooting, and a sample in a zip file attached to the post. Check it out!
How to use Custom Controls in Work Item Form
tags: tfs, team foundation server, tfs api, work item tracking
This week, a couple of people asked (forum post 1 and forum post 2) how to subscribe to the CheckinEvent notification when there's a checkin under a particular tree. The first person wanted to filter by path in order to kick off continuous integration. The second person wanted to filter by path for email subscriptions.
Here's the command line that I used to configure an email notification for a path. I've changed the email address (someone@microsoft.com), the server name (http://MyVstfat01:8080), and the path ($/TeamProject/A) from their original values, but it's otherwise what I've used to create a successful subscription.
bissubscribe /eventType CheckinEvent /address someone@domain.com /deliveryType EmailHtml /server http://MyVstfat01:8080 /filter "'Artifacts/Artifact[starts-with(@ServerItem, \"$/TeamProject/A\")]' <> null"
The difference for CI would be the delivery type and address. With that changed, the following should work (I confess I didn't try this to verify it, but it's based on the subscription in Jeff Atwood's continuous integration post).
bissubscribe /eventType CheckinEvent /address http://tsweb01:8080/ci/notify.asmx /deliveryType Soap /server http://MyVstfat01:8080 /filter "'Artifacts/Artifact[starts-with(@ServerItem, \"$/TeamProject/A\")]' <> null"
These subscriptions are a pain to create. In the future we hope to provide a tool to make this more convenient. If someone decides to put a project up on CodePlex to do it, let me know.
Naren Datha posted a nice summary of links for information on subscribing to events.
[UPDATE] I should also have mentioned that for those of you trying to filter the builds, check out Filtering the builds listed in work item tracking.
tags: tfs, team foundation server, team build, source control
For Team Build users, I'll spare you the suspense and tell you that there are no meaningful changes in Team Build itself in SP1. There are changes in other parts of the system, though, that will be of some benefit.
Version control users will get a number of fixes, but most are related to scalability.
Brian Harry described many of the TFS SP1 changes in a post in June. I'm sure he'll post a follow up soon now that SP1 beta has shipped.
You can find out how to get the SP1 beta at Microsoft Connect. Soma's post provides a higher-level description of what's in SP1 beta.
UPDATE: Rob Caron has posted the details of what's in SP1 beta.
tags: tfs, team foundation server, visual studio, vsts
You may have read about the Team Foundation activity log, which is a database table containing the web service requests executed by the server (turning it on, interesting queries, and more interesting queries). You may have also seen posts about turning on tracing, both server tracing (see Patrick Carnahan's first response) and client tracing (see my first response, or the commented-out block in tf.exe.config). Tracing produces tons of info, and it can be really useful for solving difficult issues.
What if you just want a convenient way to see the web service calls your application (or ours) makes? The performance dialog is a very convenient way to do it. James Manning and I put it and the underlying infrastructure in place about a year before TFS shipped to make it easy to find and fix performance issues, particularly on the client.
The dialog is included in the Team Foundation client assemblies. It must be registered as a trace listener in the application's .exe.config file and uses the information available in the client-side tracing to display web service calls. In the dialog, you'll see how long each call takes, the number of calls made, the average time for a call, and more.
Here's a screen shot.
The WebService column usually shows the name of the web method followed by the service being contacted. For example, "GetMetadataEx2[Wor]" is the GetMetadataEx2 web service method being called on the Work Item Tracking service. All times are reported in milliseconds.
The three-letter designation after the web service method name consists of the first three letters of the service name. Here's a list of what you'll see.
In some cases, you will not see the web method name, such as the case with the AsyncSharepoint call above, where the tracing mechanism couldn't determine the name of the call (it looks for the method name at a particular point in the stack frame). The other case where this happens is when files are uploaded and downloaded by version control. In those cases, you'll see Ver-Upload or Ver-Download and the name of the file involved.
The top section of the dialog shows the aggregated information. The bottom section of the dialog shows the list of web service methods in the order in which they were called, the elapsed time in milliseconds, and the time of day when the method completed execution. If the method has not completed, it will display "Running" for the completion time. If you move the mouse over the entries in the bottom section, a tool tip will show you the stack trace, so you can see what part of your application made the call.
The Clear button resets all of the data in the dialog. This can be really useful when you want to get information about one particular scenario. For example, you may clear the dialog and check in your changes to see what gets called in Visual Studio.
For those folks who pay really close attention, you may notice that there's a difference in the times that you see in the activity log on the server and the times that you see in the performance dialog. The difference is due to the fact that the performance dialog is showing you the entire time it took for the client to send the request and start getting the response, whereas the server's activity log shows the time it took for the server to execute the method once it received the request.
To get this dialog, you'll need to add the following to the .exe.config file for your application. If you want to see this in Visual Studio for example, you would add this to devenv.exe.config. The XML snippet goes inside the configuration element.
<system.diagnostics>
<switches>
<add name="TeamFoundationSoapProxy" value="4" />
<add name="VersionControl" value="4" />
</switches>
<trace autoflush="true" indentsize="3">
<listeners>
<add name="perfListener" type="Microsoft.TeamFoundation.Client.PerfTraceListener,Microsoft.TeamFoundation.Client, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
/>
</listeners>
</trace>
</system.diagnostics>
If you are developing an application and are concerned about performance, this is a valuable tool.
tags: tfs, team foundation server, tfs api
There's an error in the MSDN documentation on how to build Visual Studio setup projects with Team Build, which several customers have hit now (see this Team Build MSDN forum question). The result is that the build hangs; it never returns. The reason is that there's a line break in the MSBuild XML snippet on the MSDN documentation page that results in devenv (VS) being launched as an interactive process rather than with the set of arguments to build a deployment project. The result is a hang, since nothing can see the instance of VS that's been launched by the build service.
The documentation page is Walkthrough: Configuring Team Build to Build a Visual Studio Setup Project.
Here's the XML that contains the error. In step 6 of the description of the changes needed in the TfsBuild.proj file, there's a line break after "devenv"" that shouldn't be there.
</ItemGroup>
<Target Name="AfterCompile">
<Exec Command=""drive letter:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv"
"$(SolutionRoot)\HelloWorldTest\HelloWorldTestInstaller\HelloWorldTestInstaller.vdproj /Build "Debug|Any CPU""/>
<Copy SourceFiles="$(SolutionRoot)\HelloWorldTest\HelloWorldTestInstaller\Debug\HelloWorldTestInstaller.msi"
DestinationFolder="$(OutDir)" />
<Copy SourceFiles="$(SolutionRoot)\HelloWorldTest\HelloWorldTestInstaller\Debug\setup.exe"
DestinationFolder="$(OutDir)" />
</Target>
</Project>
Here's the correct version.
</ItemGroup>
<Target Name="AfterCompile">
<Exec Command=""drive letter:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv""$(SolutionRoot)\HelloWorldTest\HelloWorldTestInstaller\HelloWorldTestInstaller.vdproj /Build "Debug|Any CPU""/>
<Copy SourceFiles="$(SolutionRoot)\HelloWorldTest\HelloWorldTestInstaller\Debug\HelloWorldTestInstaller.msi"
DestinationFolder="$(OutDir)" />
<Copy SourceFiles="$(SolutionRoot)\HelloWorldTest\HelloWorldTestInstaller\Debug\setup.exe"
DestinationFolder="$(OutDir)" />
</Target>
</Project>
One of the customers that got bitten by this error noticed the incorrect new line and told us about it in email. After that, we answered a similar post in the forums. Independently, one of our testers hit the problem last week. It's funny how these things can pop up seemingly all at once.
The documentation error should be fixed with the next MSDN documentation update.
tags: tfs, team foundation server, team build, visual studio
Aaron Hallberg has written a couple of posts about Team Build that started with questions from users. The first deals with how to determine, from code, whether tests passed.
Determining Whether Tests Passed in Team Build
In a forum post a while back, I laid out a method for determining whether tests had passed during a build. More recently, I have linked to this forum post in advising others on similar problems. Unfortunately, as a sharp user pointed out in this same thread, my solution doesn't actually work, since it relies on a property that is not accessible in Team Build v1!
So - to remedy the situation I have written a custom task which can be used to determine whether tests have succeeded or not. This task takes advantage of the GetTestResultsForBuild method of the Microsoft.TeamFoundation.Build.Proxy.BuildStore class.
The second shows you how to build a specific version.
Building a Specific Version with Team Build
Team Build by default gets the latest version of your sources (or tip) from source control. For the most part, this is probably the behavior you would want and expect. But not always - you might want to reproduce a particular build that got deleted, for example; or you might want to build your latest changeset without including changes other users might have checked in.
Unfortunately, getting (and therefore building) a specific version from source control is not supported out of the box in Team Build version 1...
tags: tfs, team foundation server, tfs api, team build
Back in March, I wrote a post called How to check in changes on behalf of other users. Among other things, you'll find the documentation comments for the Workspace.CheckIn() method, which you'll notice is now on MSDN. While that and How to validate check-in policies, evaluate check-in notes, and check for conflicts are probably the best documentation on how to use CheckIn(), I didn't mention that CheckIn(), which returns the changeset created by checking in, may return 0.
The version control server automatically undoes the pending changes in the case where you attempt to check in files that haven't changed rather than create new versions of them. In the extreme case, CheckIn() will return 0 when all of the changes being checked in are edits without content changes or locks. Nothing bad happened, but the server did not create a changeset. If something bad happened, such as having one or more conflicts, CheckIn() will throw an exception.
The CommitCheckinEventArgs object, available by listening to the VersionControlServer object's CommitCheckin event, contains the list of files that were actually checked in (Changes) and the files that were undone (UndoneChanges).
tags: tfs, team foundation server, tfs api, source control
Brian Keller mentioned that the transcript of the Sept. 6th chat is now available.
Team System "Chat" transcript now available
It looks like the the transcript from our September 6th "Chat" on MSDN is now available. It was great meeting everyone who could make it - we had nearly 150 people during the live session which is simply incredible! Team System has become very popular in a relatively short amount of time, which is of course thanks to our customers. So THANK YOU for believing in the product as much as we do!
For people who couldn't attend the live chat session the transcript is a good way of catching up on common questions related to Team System. There will be another Team System chat on October 4th - get the full chat schedule here: http://msdn.microsoft.com/chats/
Aaron Hallberg represented Team Build in the chat. Here are some of the issues that were discussed. He sent these issues to rest of the team, and they'll be part of the discussion on what goes into future releases.
tags: tfs, team foundation server, team build
Occasionally the question of whether to use the TeamFoundationServerFactory.GetServer() method or the TeamFoundationServer constructor comes up, and someone recently asked this question on an internal list. The answer depends on the needs of the application that you are writing. In this post, I'll discuss the main differences between the two.
If you have an application where different parts of the code will need to access the same TeamFoundationServer object (say you need to hook up event handlers to the same VersionControlServer object that the rest of the code is using) but only have the name/URL of the server, then the TeamFoundationServerFactory is the correct choice. The TeamFoundationServerFactory caches the TeamFoundationServer objects it creates and always returns a cached TeamFoundationServer object if one matching the request exists. Those cached objects are indexed only by server URL, which is why there is no way to specify the credentials in the GetServer() method. Every time you request the TeamFoundationServer object for http://yourserver:8080, for example, via TeamFoundationServerFactory.GetServer(), you will get the same exact instance, and thus no chance to connect to the same server with different credentials.
The Team Explorer needs this type of behavior and is why TeamFoundationServerFactory exists. The different parts of the code shouldn't pop up additional login dialogs and yet the code wouldn't know how to retrieve the existing TFS object from a cache whose key included the credentials without first asking the user what credentials to use (there are also complications in dealing with CredentialCache objects; you can read more about CredentialCache objects in the post, Authentication in web services with HttpWebRequest).
However, if you want to connect to the same Team Foundation Server with different credentials, you must use the constructor. For example, you connect to server A as users X and Y.
TeamFoundationServer tfsX =
new TeamFoundationServer("http://serverA:8080",
new NetworkCredential(userX, passwordX, domain)); TeamFoundationServer tfsY =
new TeamFoundationServer("http://serverA:8080",
new NetworkCredential(userY, passwordY, domain));
The command line, tf.exe, is an example of an application that can do that via command files containing commands with /login options specifying different users. For example, you could execute the following by saving the commands in a file called cmd.tfc and running tf @cmd.tfc. These two commands execute within the context of one running instance of tf.exe, which means tf.exe must use the constructor.
edit foo.cs /login:userX,passwordX
perm $/blah/foo.cs /deny:read /login:userY,passwordY
If you don't have either of these requirements and just need a TeamFoundationServer object to do something, you could choose either. You'll find examples of both in this collection of code that uses the API. Personally, I tend to use the constructor for utility apps and examples, but there's no profound reason behind it.
If you need to prompt the user for credentials to connect to the server, see the post, How to get the login dialog when using the Team Foundation Server API. The example uses the constructor, but you can also pass the credential provider to the TeamFoundationServerFactory.GetServer() method.
tags: tfs, team foundation server, tfs api
Bernardo Heynemann wrote a nice pair of posts on using Team Build to build and deploy web projects. While he uses the recently-released continuous integration tool from Notion Solutions (Team CI), there are a number of continuous integration tools for Team Build.
Today we engaged in a task (that seemed daunting at first, but proved to be just a little hard :)) that was the one to setup a team build for Continuous Integration of one of our websites.
For you guys that didn´t know, MSBuild does not currently support Website deployment out of the box. Well, I didn´t know. And another feature missing is when a check-in occurs start the build (which is the core of Continuous Integration). Lucky bastards as we are, both have already been done. One by Microsoft and the other by Notion Solutions, Inc.
What we wanted here was:
- Launch the Team Build on every check-in.
- Get the latest source code in the server.
- Build the website solution.
- Unit test the website solution.
- If everything goes well, zip the built website files and place it in the test site /archived folder with the zip name being: ProjectName_Major_Minor_Build_Release.zip. (this one I borrowed the idea of Douglas Rohm)
- If everything goes well copy all the built website files to the test site folder, so the test site always reflect the latest check-ins.
- I had to have a way to check the team builds for all our projects without having to look in VS 2005, in two ways:
- I wanted to be notified by e-mail.
- I wanted RSS Feeds for every team build so I can get notified by RSS Bandit.
tags: tfs, team foundation server, team build
Aaron Hallberg plans to periodically post descriptions and examples of some of the more relevant Team Build web service methods. There's no good source for this information currently. Even the Team Build API documentation recently published on MSDN won't help you much, as I described here. If you have particular methods you'd like to know about sooner rather than later, be sure to leave a comment on his blog.
His first post is about the GetBuildUri() and GetBuildDetails() methods on BuildStore.
Team Build API: GetBuildUri and GetBuildDetails
As Buck Hodges recently noted, some Team Build API documentation recently made it up onto MSDN. Unfortunately, most (maybe all? I haven't been through it all) of the topics are skeletons, with no real content. I'll be trying to remedy this by posting fleshed out documentation, sometimes even with examples...
tags: tfs, team foundation server, tfs api, team build
If you haven't seen the new TreeDiff, you can see a screen shot in Brian Harry's post about the new release. It provides a VSS-style project difference tool that allows you not only to see what's changed but also reconcile changes.
Tan Phan, a developer on the version control client team, has written a post describing how to customize the TreeDiff tool. He provides a link to Michal Malecki's post about a workaround for the get latest issue as well as how to fix the file extension filtering, change colors, and more.
tags: tfs, team foundation, source control, tfpt
Mario Rodriguez, a program manager on TFS version control, is seeking your input on what you need in the way of checkin policies for a future power toys release. An example might be a policy that wraps another policy to provide path filtering to more precisely control what files are subject to a particular checkin policy.
Please leave a comment on his blog post.
Check-In Policies Pack Feedback Request
I have decided to skip the post about merge and deleted items for today in order to get some feedback from you on Check-in Policies. Currently, we are thinking of releasing a check-in policy pack out of band that includes some very commonly used policies, an example being "Check-in comment field cannot be empty".
tags: tfs, team foundation server, source control, checkin policy
Aaron Hallberg wrote a great post explaining how to build precompiled web sites with Team Build. The problem is that building them does not, by default, produce precompiled websites where all of the code is in dlls and removed from the ASP.NET source files.
Team Build and aspnet_compiler.exe
...
Because Team Build typically compiles solutions and not projects, an additional complication is introduced with website projects. By default, these projects have the -u option selected for their compilation in their solution property pages.
With this option turned on, aspnet_compiler.exe keeps markup, including inline code, in all *.aspx and *.ashx files (and possibly others - I'm no expert in these matters) so that they can be modified after the site is deployed. So - if you compile your website projects by using MSBuild to compile the solutions that contain them:
> msbuild.exe C:\MyProjects\WebApplication.sln
...your *.aspx and *.ashx files will be updatable and will not be compiled. Since Team Build typically compiles solutions, builds done through Team Build will run into the same issue.
tags: tfs, team foundation server, team build
This has come up before on the forums, but I don't think I've ever posted about it here. Today I saw a reference to the TFS Workspace Gotcha! post in today's Team System Rocks VSTS Links roundup. There's a command to deal with the problem, but it's not obvious.
Here's the post.
I have been working with a team that has recently migrated a TFS source project from a trail TFS to a full production server (different server). They disconnected their solution from source control (removes all the SCC stuff from .sln) files and then tried to add to the new TFS.
However, they were getting weird errors.
I suggested that they might not have their workspace mapped correctly to the new TFS project.
When they tried to map the workspace, they got the following error:
The Path <local path> is already mapped in workspace <machine name [old tfs server]>
Hmm, I thought we removed all the source stuff?
Turns out that the workspace mappings are stored in a file called:
VersionControl.config under the users local settings/application data directory.
I could find no way (other than manually editing the forementioned file) to remove the workspace mapping from that local folder to the other TFS server (which is no longer in usage).
Anyway, once that was done, all was good in the world.
Thanks go out to Kevin Jones for his excellent post on Workspaces in TFS.
While deleting versioncontrol.config will clear the cache, we've actually got a way to do it from the command line. The command "tf workspaces /remove:*" clears out all of the cached workspaces (it only affects the cache file). You can also specify "/s:http://oldserver:8080" to clear out only the workspaces that were on the old server. The MSDN documentation for the workspaces command is at http://msdn2.microsoft.com/en-us/library/54dkh0y3.aspx.
The reason that he hit this is due to switching servers. Every server has a unique identifier, which is a GUID. Each local path can only be mapped in a single workspace, and the versioncontrol.config cache file is the file that the client uses to determine what server to use when given a local path (e.g., tf edit c:\projects\BigApp\foo.cs).
He originally had a workspace on the old server that used the local path he wanted to use with the new server. Let's say that's c:\projects. When he tried to create the new workspace on the new server (GUID2) that he also wanted to map to c:\projects, the client saw that the old server (GUID1) was already using that local path. Since the IDs for the servers did not match, the client complained that c:\projects is already mapped to the old workspace on the old server.
The client uses the server's ID as the real name of a server. The reason is that the name could change, either because an admin changed the server's name or because a user needs to access the server through a different name depending on the connection (intranet vs. internet). The only "name" guaranteed not to change is the ID. So, when presented with a different network name, the client requests the ID from the server and compares it to the IDs listed in the versioncontrol.config cache file. If the ID matches one of them, the client simply updates the existing entry to have the new name, so that subsequent uses of the new name do not incur an extra request to check the ID. If the ID does not match any of them, then the server is different than any of the servers in the cache file.
The error message looks like it's showing the machine, but it's actually showing the workspace name. The reason for the confusion there is that the version control integration in VS creates a default workspace that has the same name as the machine.
The problem will not occur if you upgrade the same server (i.e., you don't create a new server), as an upgraded server still has the same ID.
Though /remove isn't mentioned (part 2 does mention the error message at the end), you can check out Mickey Gousset's workspace articles for more information on workspaces and managing them.
tags: tfs, team foundation server, version control
If you are interested in the TFS reporting feature, you may want to check out the sample reports in the zip file attached to the following blog post.
This attachment contains a variety of samples, experiments and untested reports for use with the Team Foundation Data warehouse. There is a brief overview document describing the reports and how to deploy them.
zip file: TFS Reporting Samples.zip
Here's what you'll find in the zip file. If you have any questions or have feedback for the team, be sure to post in the MSDN TFS Reporting Forum.
C:\msdown\TFS+Reporting+Samples>tree /F
Folder PATH listing for volume IBM_PRELOAD
Volume serial number is 002B0067 18A4:2518
C:.
? Installing the Sample Reports.doc
?
????Box Reports
? ????Box Reports
? ? Box Reports.sln
? ?
? ????Box Reports
? Actual Quality vs Planned Velocity.rdl
? Box Reports.rptproj
? Box Reports.rptproj.user
? Bug Rates.rdl
? Bugs by Priority.rdl
? Bugs Found Without Corresponding Tests.rdl
? Builds.rdl
? Issues and Blocked Work Items.rdl
? Load Test Comparison.rdl
? Load Test Detail.rdl
? Load Test Summary.rdl
? Load Tests.rdl
? Project Velocity.rdl
? Quality Indicators.rdl
? Reactivations.rdl
? Regressions.rdl
? Related Work Items.rdl
? Remaining Work.rdl
? Requirement Details.rdl
? Requirements Test History and Overview.rdl
? Tests Failing without Active Bugs.rdl
? Tests Passing with Active Bugs.rdl
? TfsOlapReportDS.rds
? TfsReportDS.rds
? Triage.rdl
? Unplanned Work.rdl
? Work Item with Tasks.rdl
? Work Item with TestResults.rdl
? Work Items.rdl
?
????Portal Reports
? ? Portal Reports.sln
? ?
? ????Portal Reports
? Bug Rates.rdl
? Copy of Quality Indicators.rdl
? Issues and Blocked Work Items.rdl
? Portal Reports.rptproj
? Portal Reports.rptproj.user
? Project Velocity.rdl
? Quality Indicators.rdl
? Reactivations.rdl
? Remaining Work.rdl
? TfsOlapReportDS.rds
? TfsReportDS.rds
? Triage.rdl
? Unplanned Work.rdl
?
????Sample Reports
? ? Sample Reports.sln
? ?
? ????Sample Reports
? 7 Day ZBB.rdl
? Area Overview.rdl
? Code Coverage.rdl
? Files by Directory.rdl
? Files by Person.rdl
? Files by Priority.rdl
? Files by Type.rdl
? Issues and Risks.rdl
? Project Schedule.rdl
? Projection.rdl
? Quality Indicators - Portal.rdl
? Quality Indicators.rdl
? Reactivations and Resolutions.rdl
? Report Gallery.rdl
? Sample Reports.rptproj
? Sample Reports.rptproj.user
? Source Code Details.rdl
? Source Code Overview.rdl
? Task Burndown.rdl
? Test List.rdl
? Tests by Category.rdl
? TfsOlapReportDS.rds
? TfsReportDS.rds
? Work Item List - Point in Time.rdl
? Work Item List.rdl
? Work Item Revisions.rdl
? Work Items.rdl
?
????TFS Report Examples
? ? TFS Report Examples.sln
? ?
? ????TFS Report Examples
? Related Work Items.rdl
? Related Work Items.rdl.data
? TFS Report Examples.rptproj
? TFS Report Examples.rptproj.user
? TfsOlapReportDS.rds
? TfsReportDS.rds
? Work Item Chart.rdl
? Work Item Chart.rdl.data
? Work Item List.rdl
? Work Item List.rdl.data
? Work Item Trend.rdl
? Work Item Trend.rdl.data
?
????Warehouse Status
? ? Warehouse Status.sln
? ? Warehouse Status.vssscc
? ?
? ????Warehouse Status
? Deployed Reports.rdl
? Query Execution History.rdl
? Query Execution History.rdl.data
? Report Execution History.rdl
? ReportServer.rds
? TfsOlapReportDS.rds
? TfsReportDS.rds
? TfsTeambuild.rds
? TfsTrace.rds
? TFSVersionControl.rds
? Warehouse Load Rates.rdl
? Warehouse Status.rdl
? Warehouse Status.rptproj
? Warehouse Status.rptproj.user
? Warehouse Status.rptproj.vspscc
? Work Item Load Status.rdl
? WorkItemTracking.rds
?
????Work Item Overview
? Work Item Overview.sln
?
????Work Item Overview
TfsOlapReportDS.rds
TfsReportDS.rds
Work Item by Priority Detail.rdl
Work Item by Priority.rdl
Work Item List.rdl
Work Item Overview.rdl
Work Item Overview.rptproj
Work Item Overview.rptproj.user
tags: tfs, team foundation server
Rob Caron mentioned that the SDK documentation is now on the MSDN web site. That SDK documentation includes the Team Foundation Server API documentation. Last year I pointed out where to find the version control documentation in the massive download that is the VS SDK, but you don't need to do that now.
So, the good news is that the documentation that we have is much more accessible. The bad news is that it's still pretty thin. Folks are working on that, but it's going to take time -- the API is pretty large.
Version Control API
Here are some pointers to some key classes for version control, which you can see used in code in the basic version control API example.
One thing to note is the format of each URL. If you know the fully qualified name of the class that you are after, you can go straight there. For example, here's the link for Microsoft.TeamFoundation.Client.VersionControlServer: http://msdn2.microsoft.com/en-us/library/Microsoft.TeamFoundation.VersionControl.Client.VersionControlServer.aspx.
You'll notice a lot of exception classes in version control Client namespace. They only really matter to you if you want to handle a very particular exception, which is generally quite rare. If you are interested in catching and handling version control exceptions, you can simply catch the base exception class, VersionControlException. The most important thing about the exceptions is that the message in the exception is intended for display to the end user, so feel free to just display the message from the exception.
You won't find any documentation on the version control GUI controls, because they aren't public. In a future release, we'll provide public GUI classes. If you are writing a VS add-in, you can find documentation on using some of the GUI controls inside of Visual Studio 2005 in Ed's post.
You can find examples of using the API in the post, Links to code samples.
Team Build API
The Team Build API is there as well. You'll want to skip most of the classes in the Microsoft.TeamFoundation.Build.Common namespace, as they aren't that useful. In fact, many of them have been marked as deprecated in post-v1 code. For example, there's a BuildData class in there, but you can't really use it (no public methods take it as input). You need the BuildData class that the proxy uses.
So, the namespace to focus on is Microsoft.TeamFoundation.Build.Proxy. This namespace contains the classes that you need to use to communicate with the server, such as BuildData.
Here are pointers to the key classes in Team Build. Everything in the Proxy namespace was generated by wsdl.exe, so you won't find any documentation with these classes. They are just the bare proxy classes used to communicate directly with the Team Build web service.
We've been working on adding a client object model for Team Build that will provide you with the same types of capabilities you get from the version control and work item tracking object models. While it's not something that will help you today, you can look forward to it in a future release.
As with version control, all of the GUI controls are private.
Work Item Tracking API
Here are some of the key classes in work item tracking.
Work item tracking does expose some of the GUI controls in version 1. You'll find the documentation in the Microsoft.TeamFoundation.WorkItemTracking.Controls namespace. If you decide to do much with WIT controls, I highly recommend Naren Datha's blog, especially the article on work item tracking client extensibility and how to configure the WIT OM for a web app.
Power Toys
The Team Foundation Server power toys that were released yesterday were written using these classes. Yes, the latest power toys do make use of some GUI classes that aren't public in v1, but they use the same object model API that's available to you. In fact, the older tfpt.exe release used only the public API and re-implemented the dialogs where it needed them (the idea being that we might release the source code in the future, but that never happened). Hopefully, we'll see more community-developed tools, like the TFS tools on CodePlex, using the API.
Speaking of the power toys, Soma wrote a post today about the TFS power toy release. He's my boss's boss's boss's boss's boss's boss. That translates to corporate VP -- the man who runs the Developer Division.
tags: tfs, team foundation server, tfs om, version control, team build, work item tracking
