Category Archives: 8971

How to configure SMTP Settings for Team Foundation Server

There are three places where you might want to configure SMTP settings:

  1. On TFS itself via » TFS Admin Console » Email Alert Settings:
    http://msdn.microsoft.com/en-us/library/ms400808(v=vs.110).aspx
  2. SQL Server Reporting Services (SSRS) via » Reporting Services Configuration Manager: http://technet.microsoft.com/en-us/library/ms345234.aspx
  3. SharePoint (SP) via » Central Admin » System Settings » Outgoing e-mail settings:
    http://technet.microsoft.com/en-us/library/cc288949.aspx

Here are some screenshots:

TFS Admin Console:
Configure SMTP Settings in TFS Admin Console

Reporting Services Configuration Manager:
Configure SMTP Settings in SQL Server Reporting Services Configuration Tool

SharePoint Central Administration:Configure SMTP Settings in SharePoint Central Administration

Where to get Team Explorer from

It can be downloaded from the Microsoft Download Center:

Notes:

  • The “Installer” versions download necessary update files from the internet.
  • (*) = Install the GDR updates if you want to use TFS 2012 or TF Service.

Download: Visual Studio 2010 Project Template for TFS Utilities

If you develop small utilities for Team Foundation Server a lot, you might want to save some time and use a project template (see bottom of post for download link) that already comes equipped with the correct references to the Team Foundation Object Model (Microsoft.TeamFoundation.*.dlls) as well as the most important using statements and a few lines of code to get started.

Installation

Copy the ZIP file to {MyDocuments}\Visual Studio 2010\Templates\ProjectTemplates.

Usage

Create a new project and select “TFS Utility” from the “Visual C#” list.

TFS Utility Project Template 

The template creates a new Windows Forms application with references to the Microsoft.TeamFoundation.*.dlls (btw: the C# compiler gets rid of all references that were not used in the project during compilation)…

 References to Team Foundation Object Model

… as well as a a few using statements and some code to start from.

Generated code in Form1.cs 

Happy TFS tool development!

Download: TfsUtility.zip

Restrict TFS to only allow connections from clients with VS SP1

You can control which clients get rejected when trying to connect to your TFS.

Scenario

You are running TFS 2010 SP1 and want to make sure that all clients have (VS) SP1 (at minimum) applied.

Luckily, you can configure which clients get rejected when trying to connect to your TFS. You can even provide the message that will be displayed to users whose clients get rejected:

image BlockNonSP1Clients_Sorry1

Solution

It’s easy, you have to add two values to the TFS registry (and restart TFS):

  • Key: /Configuration/Application/DisabledUserAgents/TFS10SP1
    Value: "Team Foundation (*.exe, 10.0.<40219.1)"
  • Key: /Configuration/Application/DisabledUserAgents/TFS10SP1/Message
    Value: "Sorry, you have to install Visual Studio 2010 Service Pack 1."

How to do that

Use the tfsreg.exe tool and run this two commands:

tfsreg.exe /server:http://servername:8080/tfs /path:/Configuration/Application/DisabledUserAgents/TFS10SP1 /value:"Team Foundation (*.exe, 10.0.<40219.1)"
tfsreg.exe /server:http://servername:8080/tfs /path:/Configuration/Application/DisabledUserAgents/TFS10SP1/Message /value:"Sorry, you have to install Visual Studio 2010 Service Pack 1."

Note: Replace the blue URI with your TFS’ server URI.

Or download the ready-to-use BlockNonSP1Clients.bat (.ZIP)

Caution: Always remember do not directly edit the TFS registry entries by editing TFS’ SQL databases manually. Always use the registry service (client or server) or the tfsreg.exe tool mentioned above (which does that) to modify TFS registry entries.

Future Compatibility Note: This mechanism might change or be implemented differently in future versions of TFS, there’s no compatibility guarantee.

Update (2 Oct 2011): In TFS 2010 older clients (VS 2005 and VS 2008) that do not have Service Pack 1 and the appropriate Forward Compatibility Upgrade installed, will be rejected by default using this technique.

(Thanks to Philip Kelley, Taylor Lafrinere, and Buck Hodges from Microsoft for this tip).

Installing TFS Build 2010 on a non-domain-joined machine

Scenario

You want to install and run TFS Build Controller and Agent on a separate network/domain than your Team Foundation Server 2010.

Disclaimer:
According to Ruiz from the MSDN Subscriber Support in Forum this is not officially supported.

How to solve:

  1. Install Team Foundation Build 2010 from TFS media.
     
  2. Apply latest updates (e.g. Service Pack 1, Cumulative Update 1).
     
  3. Create user account (both locally on the Build server as well as your TFS AT) as the service account for Team Build (e.g. TFSBUILD)
     
  4. On TFS, add service account TFSBUILD to Project Collection Build Service Accounts security group (on the collection-level)
     
    TFSBuildWithoutDomain0
     
  5. Configure the Build Server: when asked leave the "team project collection" field blank.
       
    TFSBuildWithoutDomain1
     
  6. Choose any system account for now.
     
    TFSBuildWithoutDomain2
     
  7. After configuration has completed, open the Build Service properties and set the service account to your local account (e.g. ".\TFSBUILD")
     
  8. Done. You can now start the Build Service, define a Build Controller and Build Agents.
     

More Information:

(Thanks to Wes MacDonald and Etienne Tremblay to guide me through this.)

Additional note from Wes:
The other thing I should mention is we had to have the build agent hostname defined in the HOSTS file on the TFS Application Tier and the TFS Server hostname defined in the Build Agent HOSTS file. This assumes the DNS is not configured with the entries.

Available Check-In-Policies for Team Foundation Server 2010

Note: This list will not be updated anymore. For TFS 2012, refer to the updated list.

Check-In Policies

Shipping as part of Team Foundation Server 2010:

  • Builds – Requires that build breaks that were created during a build must be fixed before a new check-in.
  • Code Analysis – Requires that code analysis is run before check-in. [More]
  • Testing Policy – Requires that check-in tests are completed before check-in.
  • Work Items – Requires that one or more work items be associated with the check- in.

Supplied by the TFS 2010 Power Tools (needs to be installed on all VS clients):

  • Changeset Comments Policy – Requires users to provide check-in comments.
  • Custom Path Policy – Allows you to scope other check-in policies to specific folders or file types.
  • Forbidden Patterns Policy – Prevents users from checking in files with filenames that contain forbidden characters or patterns.
  • Work Item Query Policy – Requires that the associated work items need to be part of the result of a specified work item query.
Note: When using an older version of VS (2005/2008) you need to install the corresponding version of the TFS Power Tools (VS 2005 requires 2005 Power Tools, etc.)
Developed by the Community:
But what about the "Override policy" checkbox?

There might always be an unforeseen reason why not all policies could be fulfilled.

Further reading:

Do you know another great check-in policy for TFS 2010? Let me know!

Updates:

Creating Fake builds in TFS Build 2010 using the command line

In TFS it’s possible to create "faked" builds, without actually running them. You can read about it in this blog post by Jason Prickett.

Main scenarios are:

  • Using a different build tool than TFS Build
    (by creating faked builds will let you use some of the great TFS features).
  • Creating sample data to show off TFS functionality

You can create "faked" builds on the command line using the following tool.

Syntax/Usage:

TfsCreateBuild.exe /collection:http://tfsserver:8080/tfs/MyCollection
/project:TeamProject /builddefinition:"Daily Build"
/buildnumber:"MyApplication_Daily_1.0"

(replace parts in blue)

Optional parameters:

  • /status:<value> Status of the build (Succeeded, Failed, Stopped, PartiallySucceeded)
  • /flavor:<name> Flavor of the build (to track test results against, default: Debug)
  • /platform:<name> Platform of the build (to track test results against, default: x86)
  • /target:<name> Target of the build (shown on build report, default: default)
  • /localpath:<path> Local path of solution file. (e.g. Solution.sln)
  • /serverpath:<path> Version Control path for solution file. (e.g. $/proj/src/app.sln)
  • /compileerrors:# Number of compilation errors.
  • /compilewarnings:# Number of compilation warnings.
  • /analysiserrors:# Number of static code analysis errors.
  • /analysiswarnings:# Number of static code analysis warnings.
  • /droplocation:<path> Location where builds are dropped.
  • /buildlog:<path> Location of build log file. (e.g. \server\folder\build.log)
  • /changesets:<ID> Changesets to associate (e.g. “/changesets:13,14,15”)*
  • /workitems:<ID> Work Items to associate (e.g. “/workitems:102,103”)*

(*) The parameters /changesets and /workitems are only available in the TE 2013 compatible version.

The result:

No, TFS cannot compile Win 3.1 apps...

Download the tool from here:

–Neno

Licensing Changes in TFS 2010: Creating work items and viewing the once created by the user does not require a CAL

Finally creating bugs from external customers is now CAL-free as well.

The real news here is that the existing exception, under which you do not need a Team Foundation Server client access license (TFS CAL), is now valid for internal as well as external users.

This is what the Licensing White Paper says:

Client Access License Exception for Certain Work Items

A user does not need a CAL or External Connector License to create new work items or to update work items that that same user has created. This exception applies only to work items related to defect filing or enhancement requests. However, a CAL is required when a user views or modifies a work item created by another user or interacts with Team Foundation Server in any other way.

[…]

Solved: Error creating a new Test Case in VS 2010

You receive the error message:

Work item type is not valid. You must specify a valid work item type.

You cannot create a new Test Case work item

Solution:

You need to import work item categories using witadmin like this:

importcategories /collection:http://server:8080/tfs/collection /p:Project /f:categories.xml

MSDN docs: http://msdn.microsoft.com/en-us/library/dd273721.aspx

You can extract the categories.xml from the Process Template definition.

(Thanks to Ruiz Yi from MSDN Subscriber Support for his post with the solution)