Wednesday, 09 August 2006

How to retrieve all event subscription made in Team Foundation Server

On of the extensibility features of Team Foundation Server is the ability to subscribe to Team System Events.  To my knowledge you can manage these subscriptions with the BisSubscribe.exe command-line utility, the client API’s or the EventService web service.   You use these tools to retrieve event subscription information if you provide the information on who created the event subscription or the subscription ID. 

Unfortunately they do not allow you to get a list of all the event subscriptions that are made on a particular team foundation server.  This can come in handy when you need an overview of and maintain the list of subscriptions on your server.  Since there is no standard way to accomplish this, I arranged a get together with my good friends Mr. Reflection, Mr. Private Method, Mrs. Internal Method and Mrs. Private Field and we came up with the underlying code sample which returns the event subscriptions for your Team Foundation Server:

/// <summary>
/// Gets all <see cref="Subscription"/> instances for a team foundation server
/// </summary>
private Subscription[] Subscriptions()
// 1. Get an instance of the types on which we will perform reflection
// The SubscriptionOnServer contains the logic for retrieving event subscriptions
Type subscriptionOnServerType = typeof(SubscriptionOnServer);
// The SubscriptionOnServer contains the logic for executing stored procedures
Type dbType = subscriptionOnServerType.Assembly.GetType("Microsoft.TeamFoundation.Server.DB");

// 2. Get an instance of the subscriptionOnServer class through its factory method
MethodInfo serivceMethod = dbType.GetMethod("Service", BindingFlags.Static | BindingFlags.Public);
object service = serivceMethod.Invoke(dbType, null);

// 3. Initialize the connectionstring property of the DB class
MethodInfo initMethod = dbType.GetMethod("Init", BindingFlags.Instance | BindingFlags.NonPublic);
initMethod.Invoke(service, new object[] { ConfigurationManager.AppSettings["ConnectionString"] });

// 4. Retrieve all the subscriptions on the server
MethodInfo AllBareSubscriptionsMethod = subscriptionOnServerType.GetMethod("AllBareSubscriptions", BindingFlags.Static | BindingFlags.NonPublic);
ArrayList allSubscriptionsOnServer = (ArrayList)AllBareSubscriptionsMethod.Invoke(subscriptionOnServerType, new object[] { });

// 5. Get the FieldInfo information for the internal subscription field on the SubscriptionOnServer type
FieldInfo subscriptionField = subscriptionOnServerType.GetField("subscription", BindingFlags.NonPublic | BindingFlags.Instance);

// 6. Get the Subscription representation of the SubscriptionOnServer instances that were retrieved
Subscription[] allSubscriptions = new Subscription[allSubscriptionsOnServer.Count];
for (int idx = 0; idx < allSubscriptionsOnServer.Count; idx++)
SubscriptionOnServer currentSubscriptionOnServer = (SubscriptionOnServer)allSubscriptionsOnServer[idx];
Subscription currentSubscription = (Subscription)subscriptionField.GetValue(currentSubscriptionOnServer);

allSubscriptions[idx] = currentSubscription;
return allSubscriptions;

You also need an application configuration file that looks this:

<?xml version="1.0" encoding="utf-8" ?>

        <add key="ConnectionString" value="Application Name=TeamFoundation;Persist Security Info=False;Initial Catalog=TfsIntegration;Data Source=QUAOAR;Integrated Security=SSPI"/>


SCM | Team System
08/09/2006 11:29:59 UTC  #  Comments [0] 
 Tuesday, 04 July 2006

Work Item Association during check-in

Visual Studio 2005 Team System allows you to add the work item association check-in policy, to your Team Project. It requires you and other team members to associate a work item with each check-in, which is great. 


However, it does allow you to associate work items from a team project that is different from the one your changes belong to.  If you have 2 team projects A and B, you are allowed to associate a work item from team project A with changes that were made in team project B.

I’m looking for a valid reason why this should be allowed, so if you have an idea as to why, do not hesitate to help me out here…

Despite the fact that there could be a valid reason to do this, I created a check-in policy that ensures you that you are only allowed to associate a work item for the team project to which the changes belong.  This means you can only associate work items for team project A with changes from team project A.

Update: Removed duplicate PolicyFailure entries.

using System;
using System.Collections.Generic;
using System.Text.RegularExpressions;
using System.Windows.Forms;

using Microsoft.TeamFoundation.VersionControl.Client;

namespace CheckForCommentsPolicy
/// <summary>
/// This policy will check if there is a relationship between the team project to which the pending changes belong to and the team project to which the work items associated with a check-in belong.
/// </summary>
public class ValidateWorkItemAssociation : PolicyBase
/// <summary>
/// Creates a default instance of the <see cref="ValidateWorkItemAssociation"/> class.
/// </summary>
public ValidateWorkItemAssociation()
InstallationInstructions = @"Create a new string value under [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\TeamFoundation\SourceControl\Checkin Policies]\nKey: ValidateWorkItemAssociationPolicy\nValue: full name of the ValidateWorkItemAssociation.dll file.";

/// <summary>
/// This string is a description of the type of our policy. It will be displayed to the
/// user when they select our policy type in the list of policies installed on the system
/// as mentioned above.
/// </summary>
public override string TypeDescription
get { return "Checks the relation between the pending changes and the related work items"; }

/// <summary>
/// This is a string that is stored with the policy definition on the source
/// control server. If a user does not have our policy plugin installed, this string
/// will be displayed. We can use this as an opportunity to explain to the user
/// how they might go about installing our policy plugin.
/// </summary>
public override string InstallationInstructions
return base.InstallationInstructions;
base.InstallationInstructions = value;

/// <summary>
/// This string is the description of the policy. It will be displayed to the user in a list
/// of all installed policy types when they are creating a new policy.
/// </summary>
public override string Description
get { return "This policy will check if there is a relationship between the team project for the pending changes and the team project of the associated work items."; }

/// <summary>
/// This string is the type of our policy. It will be displayed to the user in a list
/// of all installed policy types when they are creating a new policy.
/// </summary>
public override string Type
get { return "Check the relation between the pending changes and the related work items."; }

/// <summary>
/// This method is invoked by the policy framework when the user creates a new checkin
/// policy or edits an existing checkin policy. We can use this as an opportunity to
/// display UI specific to this policy type allowing the user to change the parameters
/// of the policy.
/// </summary>
public override bool Edit(IPolicyEditArgs policyEditArgs)
// no configuration to save
return true;

/// <summary>
/// This method performs the actual evaluation. It is called by the policy framework at various points in time
/// when policy should be evaluated. In this example, we invoke this method ourselves when various asyc
/// events occur that may have invalidated the current list of failures.
/// </summary>
public override PolicyFailure[] Evaluate()
// Make sure we are notified when the user changes his selection of work items
this.PendingCheckin.WorkItems.CheckedWorkItemsChanged -= new EventHandler(CheckedWorkItemsChanged);
this.PendingCheckin.WorkItems.CheckedWorkItemsChanged += new EventHandler(CheckedWorkItemsChanged);

List<PolicyFailure> failures = new List<PolicyFailure>();

foreach (WorkItemCheckinInfo info in this.PendingCheckin.WorkItems.CheckedWorkItems)
if (PendingCheckin.PendingChanges.AffectedTeamProjectPaths.Length > 0)
// Get the affected team project path for the first check in
string affectedTeamProjectPath = PendingCheckin.PendingChanges.AffectedTeamProjectPaths[0];
Regex matchTeamProject = new Regex("[^$/][^/]*");
// Retrieve the team project name for the pending change
string affectedTeamProjectName = matchTeamProject.Match(affectedTeamProjectPath).Value;
if (affectedTeamProjectName != info.WorkItem.Project.Name)
new PolicyFailure(
string.Format("Work item with ID '{0}', is not a work item for team project '{1}'.",
info.WorkItem.Id, matchTeamProject.Match(affectedTeamProjectName).Value)
, this)
return failures.ToArray();

/// <summary>
/// This method is called if the user double-clicks on a policy failure in the UI.
/// We can handle this as we please, potentially prompting the user to perform
/// some activity that would eliminate the policy failure.
/// </summary>
public override void Activate(PolicyFailure failure)
MessageBox.Show("Please associate a work item that belongs to the same team project as your pending changes.");

/// <summary>
/// This method is called if the user presses F1 when a policy failure is active in the UI.
/// We can handle this as we please, displaying help in whatever format is appropriate.
/// For this example, we'll just pop up a dialog.
/// </summary>
public override void DisplayHelp(PolicyFailure failure)
MessageBox.Show("This policy helps you make sure that you associated work items to a check-in that belong to the same team project as the pending changes.", "Prompt Policy Help");

/// <summary>
/// Called when the user changes the work item selection during a check-in
/// </summary>
private void CheckedWorkItemsChanged(object sender, EventArgs e)

SCM | Team System
07/04/2006 09:31:25 UTC  #  Comments [2] 
 Friday, 23 June 2006

Reminder: Visual Studio Team System Workshop by VISUG



The Belgian Visual Studio User Group organizes a 1 ½ day seminar around Visual Studio Team System on 30 June and 1 July.  There are still some seats available, so if you are interested in learning about Team System in a User Group kind of way (real high risk live demo's, with live coding and hopefully a happy ending :-) )



This day and a half community event provides VISUG members with deep dive information on Visual Studio Team System 2005. During this event we will demonstrate the capabilities Visual Studio Team System 2005 in a way only user group can: not in theory but by live examples.


Event Outline:

        Event Overview : Overview, Business value of VSTS, core scenarios, licensing

        Planning for VSTS: Hardware and software requirements, selecting projects or solutions

        Deploying & Maintaining Team Foundation Server: Installation, Administration, back up and restore

        Working with Team Foundation Server: Architectural overview, services, extensibility

        Team Projects & Reporting: Project planning, methodology, reports

        Process Template Customization: Process guidance, work item types, workflow

        Source Code Control: Overview, migration, administration

        Building Code (MSBuild): Overview, customization

        Architect Tools: Application designer, class designer, logical datacenter designer, SDM SDK

        Developer Tools: Profiling, code coverage, code analysis

        Testing Tools: Test management, test types, unit testing

        Integration Scenarios: Commonly encountered integration scenarios



Friday 30 June 2006 from 13:00 until 17:00
Saturday 1 July 2006 from 9:00 until 16:00




Compuware Belgium


How to register:
Send an email to Steven Wilssens, which contains your name and the fact that you want to attend the event. Remember, there are 30 seats available for this event, so register as soon as possible.


Subscription Fee:

As with all Visual Studio User Group events, it is available to our Visual Studio User Group Members at no cost.

SCM | Team System | VISUG
06/23/2006 08:47:09 UTC  #  Comments [0] 
 Wednesday, 15 March 2006
 Sunday, 05 March 2006

Sildes: Advanced Source Control: Beyond CheckOut and CheckIn

During the Belgium Developer and IT Pro Days , I’ll be presenting my session on Best Practices for Advanced Source Control: Beyond CheckOut and CheckIn. I think I’m pretty close to the final version of the slides but would really appreciate your feedback! So it would be very much appreciated if you could download the slides and leave a comment or send me an email.

Update: You can find the updated presentations in: PART I and PART II.

SCM | Team System
03/05/2006 20:37:58 UTC  #  Comments [0] 
 Monday, 11 July 2005

SCM and Team System, a marriage made in heaven?

In a previous post I stated the goals of successful configuration management and as you undoubtedly realized they are not easily accomplished in the field.  Now I'll try to give you an insight on how Team System helps you to tame this untamable beast.

A good SCM process makes it possible for developers to work together on a project in an efficient manner, both as individuals and as members of a team.  A development team must constantly manage requirements, tasks, source code, bugs and reports.  Gathering each of these item types in the same tool strengthens the communication pathways of teams and software.

Based on the goals mentioned in the previous post on SCM I'll try to indicate how Team System helps you to accomplish them:

·   Configuration identification:  This is often reffered as the process of recognizing the baseline applicability to a set of configuration items. It refers both not only to source, but all documents that contribute to the baseline.  Examples are:
·   All code files
·   Compilers
·   Compile / build scripts
·   Installation and configuration files
·   Inspection lists
·   Design documents
·   Test reports
·   Manuals
·   System configurations (e.g. version of compiler used)
Team System provides this capability through the concept of Work Item Tracking. A work item can define any unit of information that is part of the software development lifecycle. It can be any of the abovementioned Configuration Items. A powerful feature of Team System is that you can link work items to other artifacts, this allows your developers and manager to track which changes are related to which requirements, bugs.

·   Configuration Control:  Refers to the policy, rules, procedures, information, activities, roles, authorization levels, and states relating to the creation, updates, approvals, tracking and archiving of items involved with the implementation of a change request.
With Team System policies can be created and enabled inside Visual Studio that will enforce following standard check-in conditions, as well as others:
·   Clean Build: The project must compile without errors before check-in.
·   Statis Analyses:  Static analyses must be run before check-in
·   Testing Policy: Smoke-tests, unit-tests must be run before check-in
·   Work Items: On ore more work items must be associated with the check in.
You can also configure Team System to trak additional check in notes.  The standard notes in MSF Agile are: Security Reviewer, Code Reviewer and Performance Reviewer.  As with the most part of Team System, this is again fully custumizable.
Roles and authorization levels are covered by Team System Security.  By locking down privileged operations to only a few members, you can ensure that the roles within your team are always enforced.  You can for example specify which team members can administer, start or resume a build and so much more.

·   Status accounting: Recording and reporting the status of components and change requests and gathering vital statistics about components in the product.
Team System is hosted on SQL Server 2005 and its built-in reporting capabilities. As many as 50 pre-built reports are expected to ship with the release of Team System. These will include reports on: Project health, code churn, test pass, test coverage, active bugs,... These reports are directly available from the Reporting Services report manager portal or can be viewed on the project portal.

·   Configuration verification and audit: Verify that a product’s requirements have been met and the product design that meets those requirements has been accurately documented before a product configuration is released.Before acceptance into the live environment, new Releases, builds, equipment and standards should be verified against the contracted or specified requirements.
This is where the Dynamic Systems Initiative (DSI) comes into play.  DSI is a way to design for deployment or to put it in another way to design for operations. Key features of DSI are:
·   The visualization of systems and services
·   tracking of each system or service to properly describe it to another system or service.
It will in other words allow solution architect's to validate their design against an infrastructure architects's datacenter design and visa versa.  The first Microsoft implementation of DSI will be called the System Definition Model (SDM).  SDM describes your application and its deployment environment in layers.  The following layers are defined:
·   Application
·   Application Hosting
·   Logical Machines and Network Topology
·   Hardware
Microsoft will furter expand on their Dynamic Systems Initiative and will utilize the SDM model in Systems Managment Server(SMS) and Microsoft Operations Manager(MOM).

·   Build management:  Manage the processes and tools that are used to create a repeatable and automatic build.
Team System's Team Build provides an out-of-the-box solution to meet following requirements:
·   Get source code files for the build from the source code repository
·   Run static code analysis
·   Compile sources
·   Run unit tests
·   Save code churn, code coverage and other build information
·   Copy the binaries to a predefined location
·   Generate reports
The build automation tool in Team System provides you with an out-of-the box solution to meet these requirements.  The wizard helps you create an automated build script. Since the execution engine of Team Build is MSBuild, you can customize the process and accomplish any number of custom tasks.


Process management:  Enforces consistent processes and promotes user accountability across the application life cycle, resulting in communication and productivity improvements enterprise-wide.
Team System will include two Microsoft Solution Framework(MSF) methodologies:  

·   MSF for Agile Software Development
·   MSF for CMMI improvement
While in MSF Agile it is more important to respond to change than to follow a plan, it is my understanding that MSF for CMMI process improvement is the only MSF methodology that fully provides process management support.  It is an excellent process to use on your project if your company is looking to achieve a measured, baseline competency in software development.  In short it will bring the process management side of the application lifecycle to your company and project.

·   Teamwork:  Controlling the work and interactions between multiple developers on a product.
One of the great advantages of the fact that Team System is such a highly integrated environment, is that it can instantly improve the communication on your team. All members of a team need to be in sync, watching their managers and need to work together to get their assignments done in time. Managers can always consult what the state of the project is, how much code churn is in the nightly builds, when the project has reached zero bugs,... Your team must constantly manage the same requirements, tasks, source, code bugs and reports. Because of the ways these are integrated in Team System it will automatically strengthen the communication pathways of your team and software.

I hope that by now you will agree that Team System is the new do-it all tool in the SCM's toolbox.  Team System is not a methodology or process but it integrates very well with the MSF methodology. Team System integrates most of the current tools that a Software Configuration Manager has dreamt about.  Microsoft will provide third party tool providers and yourself with an SDK that allows you to take advantage of common functionality that Team System provides.  Well, I cannot imagine a SCM that is not eagerly anticipating the release of Visual Studio 2005 Team System, but only time will tell.

SCM | Team System
07/11/2005 20:47:44 UTC  #  Comments [2] 
 Monday, 25 April 2005

What is Software Configuration Management?

Software Configuration Management (SCM) means many things to many people.  An excellent place to start is to define the goals of SCM.  A good SCM process makes it possible for developers to work together on a project in an efficient manner, both as individuals and as members of a team.  Based on different publications we can state that successful configuration management should enable the following:

·         Configuration identification:  Developers should be able to work together on a project, sharing common code.  This allows a developer to fix a bug in the source code for release A while another developer is developing a new feature that is scheduled for release B.

·         Configuration control:  Ensures that proposed changes to configuration items are fully coordinated and documented.  This can for example include the switch from .NET 1.1 to .NET 2.0.

·         Status accounting audit:  Recording and reporting the status of components and change requests and gathering vital statistics about components in the product.  For example: How many files were affected by fixing a bug.

·         Configuration Verification and Audit: Verify that a product’s requirements have been met and the product design that meets those requirements has been accurately documented before a product configuration is released.  It’s important to remember that this state needs to be maintained through the entire project lifecycle.

·         Build management: Manage the processes and tools that are used to create a repeatable and automatic build.

·         Process management: Enforces consistent processes and promotes user accountability across the application life cycle, resulting in communication and productivity improvements enterprise-wide.  You can really see this as getting the heads pointing in the same direction.

·         Teamwork: Controlling the work and interactions between multiple developers on a product. For example, this addresses the question, "Were all the locally made changes of the programmers merged into the latest release of the product?"


SCM did not grow out of a managers wish to limit and control developers in their creativity.  It is there to protect you from rogue behavior.  The "active rogue" is easier to identify and control because it's out in the open and often verbal.  The passive rogue is pretty much anyone on the team who will sacrifice quality when the heat starts to rise.  

When crunch time comes, and it will come believe me, you need a process that keeps people from being tempted to put in quick fixes that ultimately degrades the quality of your application. 


I hope that this post has given you an understanding of what SCM has to offer to yourself and your organization.  In a following post I will elaborate on the theoretical and practical sides of the wonderful world of the software configuration manager.


04/25/2005 20:29:32 UTC  #  Comments [0]