Category Archives: 2796

Turning off policy overrides in TFS

The Goal

Check-In policies have been around since the first version, TFS 2005, to help a team define a list of steps they want to perform prior the checking in. If a policy is not met, it alerts the user.

When policies fail, there is an option to “override” the warning(s) and continue with the check-in (the policy warnings will still be stored as part of the changeset).

Figure 6.6 CheckIn Policy Violations

While it’s easy to set up an alert to get notified when this happens, or query the TFS Warehouse to get a list of all overrides, there’s no built-in way to turn off overrides entirely.

The Solution

A server-side plug-in that intercepts all check-ins and rejects the changeset if it is a policy override. After activating the plug-in (which is simply a drag & drop of the plug-in .DLL into a specific folder on the TFS Application Tier), this is what happens if users try to override:

No Policy Overrides

How to set it up

  • To install, copy TFS.VersionControl.NoPolicyOverrides.dll to the “PlugIns” folder, located at: %ProgramFiles%\Microsoft Team Foundation Server 12.0\Application Tier\Web Services\bin\Plugins
  • Download the .ZIP package with all event-handlers here (for TFS 2013 only!).
  • To uninstall, just remove the .DLL from the “PlugIns” folder.

A word of warning

Disclaimer:
Server-side event handlers must be very well written. As they run inside of the TFS process itself, they can crash TFS, significantly degrade performance or change the behavior of built-in operations (e.g. a badly written plug-in could cause new team project creation to fail).

Note: Server-side plug-ins work on TFS on-premises only (not with Visual Studio Online).

Enjoy!

–Neno

Extending TFS’ default behavior using server-side plug-ins

In TFS 2005, Check-In Policies helped to ensure certain rules prior to check-in. However, check-in policies are executed locally and you must ensure they are available for the client (in the appropriate version) and installed.

In TFS 2010, Gated Check-Ins were introduced, which allowed validations such as the compilation, unit test execution and more (basically whatever the build script specified) to be run on the server-side and reject the check-in if they failed.

Also with TFS 2010, Microsoft introduced server-side plug-ins, which can handle TFS events and either react to them, or – in some cases – even cancel operations. Technically those plug-ins are implementing the ISubscriber interface (see this blog post how to write and debug them).

A word of warning:

Disclaimer:
Server-side event handlers must be very well written. As they run inside of the TFS process itself, they can crash TFS, significantly degrade performance or change the behavior of built-in operations (e.g. a badly written plug-in could cause new team project creation to fail).

Here’s an example:

Instead of using a check-in policy to enforce that changesets must have comments, a server-side plug-in could be used instead. This would guarantee that our rules are enforced, regardless of the client accessing TFS and if the appropriate check-in policy is available and installed for that client or not.

The server-side plug-in is installed by just copying a single .DLL to a “PlugIn” folder on the TFS Application Tier (or all Application Tier if you have more than one).

The following screenshots show how the message looks like that users will see that try to check-in without a comment.

In Visual Studio:

image
In Windows Explorer (via TFS Shell Extension from TFS Power Tools):

image
In Eclipse:

image

How to set it up

  • To install, copy TFS.VersionControl.RequireChangesetComments.dll to the “PlugIns” folder, located at: %ProgramFiles%\Microsoft Team Foundation Server 12.0\Application Tier\Web Services\bin\Plugins
  • Download the .ZIP package with all event-handlers here (for TFS 2013 only!).
  • To uninstall, just remove the .DLL from the “PlugIns” folder.

Note: Server-side plug-ins work on TFS on-premises only (not with Visual Studio Online).

Enjoy!

–Neno

Available Check-In Policies for Team Foundation Server 2012

Shipping as part of Visual Studio 2012:

  • Builds – Requires that build was successful (CI builds) and therefore build breaks must be fixed before a new check-in.
  • Changeset Comments Policy – Requires that user provide comments on check-ins. (new in VS 2012)
  • Code Analysis – Requires that Code Analysis is run before check-in. [More]
  • Work Items – Requires one or more work items be associated with the check-in.

Note: The Testing Policy that shipped with VS 2010 is not longer available.

Added after installing TFS 2012 Power Tools (needs to be installed an all VS clients):

  • Custom Path Policy – Allows you to scope other check-in policies to specific folders or file types.  [See here for how to use it.]
  • 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 (2008/2010) you need to install the corresponding version of the TFS Power Tools (VS 2008 requires 2008 Power Tools, etc.)

Developed by the Community:
  • Code Review Checkin Policy – allows to enforce Code Reviews prior to check-in (by Colin Dembovsky). Get it here.
  • Checkin Time Tracker v3 – allows you to gather effort values from developers during check-in (by AIT TeamSystemPro Team). Get it here.
  • Column Limit Check-in Policy – prevents users from checking in files that don’t comply with your column limit coding style guidelines (by Gambitrex). Get it here.
  • Merge / Branch Only Check in Policy – Block check ins that are not part of either a branch or merge operation (by Leon Mayne). Get it here.

Note: When using an older version of VS (2008/2010) you need to install the corresponding version of the check-in policies (for a list of check-in policies for VS 2010, see here).

What about the "Override Warnings" link?

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

How can I deploy custom Check-In Policies to all team members?
How can I create custom Check-In Policies?:

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

–Neno

Updated (May 17th, 2013): Added Merge / Branch Only Check in Policy.

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:

Could not write lines to file FileListAbsolute.txt. Access to the path is denied.

You receive the following error message:

C:\WINDOWS\Microsoft.NET\Framework\v4.0\Microsoft.Common.targets(3246,9): error MSB3491: Could not write lines to file "obj\Release\abc.Common.vbproj.FileListAbsolute.txt". Access to the path ‘c:\TFS Builds\Sources\abc\obj\Release\abc.Common.vbproj.FileListAbsolute.txt’ is denied.

Possible Cause:

Have you checked in the "obj" and "bin" folders?

To resolve this issue:

  1. Delete the "obj" and "bin" folder in source control.
    (usually those are not checked in)
  2. Delete the "obj" and "bin" folders on your hard disk.
    (they will be re-created during build)

Download files from TFS version control and set the file last access timestamp to the file’s last check-in time

Often I hear the following questions about TFS version control:

  • Can I just download files or folders from TFS without having to create a workspace?
  • Can I specify that files do not have the read-only attribute set?
  • Can I configure that files show the last check-in time as last write time?
  • Can can I "export" files from TFS and remove the bindings to my TFS?

The answer is: Yes, you can!

Using tfsexport.exe:

Corrected the typo - Thanks, Matt!

A few notes on what the tool offers:

  • Files/Folders are downloaded from TFS without requiring a workspace.
  • There is no read-only flag set on the files exported.
  • Optionally sets the file time to the time of last check-in.
  • Optionally removes the source control bindings (from VS solution/project files).

Download the tool from here:

Prerequisite: This tool requires Team Explorer to be installed.

(Special thanks to Grant Holliday and Marcel de Vries)

–Neno

Clean old and unused workspaces and shelves from your TFS

The command line utility "tfsclean.exe" helps  with two scenarios:

  • You want to find and delete old worspaces and shelvesets (oder than XX days).
  • You want to find and delete workspaces and shevlesets from a certain user
    (e.g. when the user left the company)

Caution: There’s no way to recover a shelveset once it is deleted.

Usage:

tfsclean.exe /collection<URI> [/delete] [/maxage:n] [/username:text] [/excludeworkspaces] [/excludeshelvesets]

Required parameters:  
/collection:<URI> URI of Team Project Collection (e.g. http://servername:8080/collection)
Optional parameters:  
/delete Required to actually delete items (otherwise it runs in readonly mode)
/maxage:<number> Specified the maximum age in days (default is: 365)
/username:<name> Only clean items from specified user (e.g. DOMAIN\username)
/excludeworkspaces Do not clean workspaces.
/excludeshelvesets  Do not clean shelvesets.

tfsclean cleans up old workspaces and shelvesets

(Note: The user needs to have the ‘Administer workspaces‘ and ‘Administer shelved changes‘ permission on TFS)

Download the tool from here:

Prerequisite: This tool requires Team Explorer to be installed.

–Neno

How to add a source control folder to an existing team project

When double-clicking the Source Control node of a Team Project that has no source control folder you receive the following message:

No Source Control Folder

Cannot open $/Projectname. Source control has not been configured for this team project, you do not have permission to acces it, or the team project has been moved or deleted.

The option to create a source control folder is gone!

What happened?
  • In TFS 2010 there is no option in the Team Project Creation Wizard to create a team project without source control (as it was possible in TFS 2008).
  • Therefore the prompt that asks if the user wants to recreate that folder, was removed as well.
Workaround:
  • Use the TFS Object Model, specifically:

    VersionControlServer.CreateTeamProjectFolder(TeamProjectFolderOptions)
  • Alternatively, I created a small command line utility that does exactly that.

    Download: CreateRootFolder.zip 

    SNAGHTML1d5f9e1

Prerequisite: This tool requires Team Explorer 2010 to be installed.

(Thanks to Chandru R. from Microsoft for this tip and the support to resolve the issue)

See and possibly unlock files checked out by other team members

Ed Hintz points out that this is easily done with TFS Power Tools and wrote about it in 2007.

  1. In the Source Control Explorer, right click on a parent folder that contains the pending change and choose, “Find in Source Control”.
  2. Choose "Status…".

    Find in Source Control command from TFS power tools
  3. Press the Find button. (optionally you can type in a user and\or wildcards if you want to narrow the search)

    Optionally filter for user and/or wildcards
  4. You will be presented a “Find in Source Control” window.
  5. Select the pending change and press the undo button OR right click Undo…

    Can easily undo changes of other users
  6. Done.