Thursday, April 21, 2011

Custom Check-in Policies for TFS 2010

I was showing a demo to a client on custom policies the other day. We went through a couple of caveats that exists between the TFS 2008 and TFS 2010 way of doing things.
If you look long enough you will find specific posts or conversations on individual issues. I decided to do a post that encompasses these issues, and a couple of my findings while creating these custom policies in TFS 2010.

Creating the custom policy is fairly straight forward. Using Visual Studio, create a new class library and add a reference to “Microsoft.TeamFoundation.VersionControl.Client.dll”.

Next create the class that you will be using and inherit from “Microsoft.TeamFoundation.VersionControl.Client.PolicyBase” and implement the methods. You should have something like this:

using Microsoft.TeamFoundation.VersionControl.Client;

 

namespace TeamFoundation.CommentPolicy

{

    public class CommentWordCountPolicy : PolicyBase

    {

        public override string Description

        {

            get { throw new System.NotImplementedException(); }

        }

 

        public override string Type

        {

            get { throw new System.NotImplementedException(); }

        }

 

        public override string TypeDescription

        {

            get { throw new System.NotImplementedException(); }

        }

 

        public override bool Edit(IPolicyEditArgs policyEditArgs)

        {

            throw new System.NotImplementedException();

        }

 

        public override PolicyFailure[] Evaluate()

        {

            throw new System.NotImplementedException();

        }

    }

}

The “Type” property can be related to the friendly name of the policy. Interestingly enough, the “TypeDescription” property is the description shown on the “Add Check-in Policy” dialog (Figure 1), and the “Description” property is the description shown in the description column of the “Check-in Policy” tab (Figure 2) when the policy is selected.

 Add Policy Dialog
Figure 1: Add Check-in Policy Dialog

Active Policy Dialog
Figure 2: Check-in Policy Tab

The “Edit” method is where you would handle any custom configuration that you may require. This method is executed before the policy is added to the list in figure 2 and when you click the “Edit” button while the policy is highlighted in the Check-in Policy tab (Figure 2). Note that if you return “false” in this method the policy will not be added to the active list. In addition, the “PolicyBase” class has a property “CanEdit” that you can override manually. If you return false for this property the “Edit” method will not be executed and the “Edit” button next to the list in figure 2 will be disabled.

Next up is the “Evaluate” method, this is where all the magic happens. You have access to the protected property “PendingCheckin” which provides pretty much all the information that you would need to devise some weird and wonderful policies. If the “Evaluate” method returns an array containing a valid instance of a “PolicyFailure” class, the check-in will show you the policy violation.

So once you have populated the properties and methods accordingly the next point is of utmost importance. You must mark your class as Serializable. If you do not, your new policy will simply not show up in the available policies list.

Next up you need to register the policy in the registry under the following path: [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\TeamFoundation\SourceControl\Checkin Policies].

Create a new String Value with the name of the assembly that contains your policy excluding the .dll extension and the value being the full path to your assembly. Example :
Name: TeamFoundation.CommentPolicy
Value: C:\Projects\Policies\TeamFoundation.CommentPolicy.dll

This should complete the steps to create and register a new check-in policy. The only thing left is to deploy the policy on each workstation that is to adhere to the policy. If you do not do this an error will be displayed that the policy is not installed, and it will be disregarded. The TFS 2010 Power Tools however have a “new” way of deploying these assemblies, but it is still up to the developer to opt in to the deployment mechanism.

zippedFile
TeamFoundation.CommentPolicy.zip

 

Logo 60x50

Monday, April 11, 2011

TFS & VS 2010 and the Database Developer

 

I was working at a client last week, giving them an overview of Database Development using Visual Studio 2010 Database Professional (DBPro). They mentioned the TFS Provider for SQL Server Management Studio (SSMS) and their attempts in trying work with it.

It had been a couple of years since I looked at it last (honestly before DBPro was released). You can download (it’s free) the plug in from here (created by the famous Martin Woodward). I noticed that it had in fact been updated to work with TFS 2010. So I decided to give it a spin.

Firstly I must highlight one of the (in my opinion) less know features in SSMS, you can create and manage projects in pretty much the same way you do in Visual Studio.

After installing the TFS Provider, make sure that SMSS knows that you are using a Source Control plugin. Select Tools | Options. Select “Source Control” and if it has not already updated, change the current plug-in to “Team Foundation Server MSSCCI Provider”.

Team Foundation Server MSSCCI Provider

Now select the File | New | Project menu option and a pretty familiar looking dialog will appear

image

Once the project has been created open up the “Solution Explorer” ( View | Solution Explorer ) and the project layout is shown

image

Right click on the “project name” and select Add | New Item. Notice that you start to get the same experience as you would in Visual Studio. You have the ability to add a number of “different” items to the project. Different categories have different templates etc..

image

And now with the Source Control plugin you can add this “Solution” or “Project” to source control (as you would a Visual Studio Project) and perform source control related check-in’s and outs, view history, compare etc. etc..

Using SSMS you still do use scripts to manage your “database”. If you only have access to Visual Studio 2010 Professional (or not at all) then this is possibly an option to evaluate (you still would need a TFS CAL).

Both SSMS and DBPro use scripts to manage your schema (DBPro has a nice “schema view” that shows you the database schema represented via scripts though), BUT with all the additional functionality that DBPro offers, including database comparisons, unit testing and data generation, I definitely prefer DBPro.

 

Logo 60x50

Friday, March 18, 2011

Visual Studio Setup project is on its last breath!

 

I was reading Buck Hodges’ blog this morning and came across an interesting piece of information: The age old Visual Studio setup project (vdproj) is coming to an end. After Visual Studio 2010 it will no longer be supported.

Personally I’ve been expecting that something would be happening around the installer experience in Visual Studio for a while now. There was quite a bit of excitement about the inclusion of WiX in VS2010. But alas, this was not to be.

Now don’t get me wrong, I have worked with WiX for a while now and it is immensely powerful. In fact a number of Microsoft’s applications are shipped using a WiX based installer, but there is nothing quite like the Visual Studio setup wizard for creating a quick and easy installer for the small, simple apps. I suppose this is where the “InstallShield 2010 Limited Edition” project support in VS2010 comes from (I must admit though, I have not really taken a good hard look at the InstallShield project yet).

I also need to say that some of the changes in WiX 3.5 (including assembly harvesting) do make it easier to deploy large projects, and you have some free, and commercial, WiX editors (I use WiXEdit) to help out.

It will be interesting to see how the support for WiX grows after the default Visual Studio setup project dies. I would recommend that now is a good time to  start looking closer at the installation technology that you are going to be choosing going forward (Microsoft has put up a nice comparison between the Visual Studio Setup, InstallShield and WiX as a guide).

Wednesday, March 16, 2011

Upgrade Visual SourceSafe today!

 

If you do not already know Visual SourceSafe’s mainstream support is coming to an end July 2012. This means that if you are still using SourceSafe after this date and you have a serious problem, too bad! (unless you are willing to pay for the extended support.)

So if you have not already though about upgrading, it is probably advisable to start looking at options.

Over the last couple of week I’ve noticed a bigger push from Microsoft to upgrade with pricing specials and more information around migrating to Team Foundation Server 2010 (being the de-facto Microsoft upgrade path).

If you have not yet looked at your options, do take a look at the following resources:

That said, if you happen to be in South Africa and would like more information or advice feel free to give us a shout

Tuesday, March 8, 2011

Visual Studio 2010 SP1 released

Finally!

Very unceremoniously Microsoft has announced that the Visual Studio 2010 Service Pack 1 will be available today (8th March ) for download for MSDN Subscribers, and will be generally available for download on March 10th, 2011.

This brings with it some very exiting bits (in addition to fixing some very annoying bugs). Some of my personnel favourites include:

  1. IIS Express Support (still need to install it separately though)
  2. Silverlight 4 tools are included
  3. Performance wizard for Silverlight (to profile Silverlight apps)
  4. Unit Testing under .Net 3.5 (previously they all ran under .Net 4)
  5. Initial HTML 5 support

On TFS SP1 most of the changes were focussed to allow the Team Foundation Server 2010 and Project Server Integration Feature Pack, in addition to a fairly large number of bug fixes outlined here by Brian Harry.

Oh and while we’re at it, don't forget about the Team Foundation 2010 Power Tools March 2011 release Smile

Thursday, January 20, 2011

A new year…

Somehow, somewhere we have entered into a new year and 2010 has drawn to a close!

After all the hype and expectation of 2010 I think a lot of people are a bit disappointed and/or let down, especially with the “global financial crisis” and the SA 2010 soccer world cup not delivering all that was promised and expected for the local economy.

For Team Foundation Consulting I must admit, it is has been going a bit better than I expected. It is about 6 months down the line and I was surprised at the interest that we were getting during the end of the year – a period  I though would be pretty dead for a young business like this, and then in January things are also starting to look good.

None-the-less it is now time to bed down how to grow this business in 2011 into a viable operation. And first on my list of things is still to “spread the word” and create awareness. At the moment we are looking at some online advertising options (more on that in another post).

There is also still a lot that needs to be done with regards to standardising past and existing engagements with a bunch of ideas that I have, into formal outlines and marketable “products”. I do find that in some cases it is easier to give people a standard, yet relevant “product” as apposed to asking them to “compose” one that will suit them. This should also enable me to start advertising approximate costs on the site, which should make people more inclined to contact us if they have an idea of what the charges could be.

I’m sure that this will be an interesting year for us, especially with the end of mainstream support for Visual Source Safe in sight and Team Foundation Server being the logical upgrade.

So to everybody that may be reading this, I wish you all the best in the new year!!!

See you around! Smile

Tuesday, November 23, 2010

TFS Security Overview

TFS security can be an interesting beast to work with from an administration point of view.
Not only do you have to manage the permissions assignments in 3 different places (TFS, SharePoint and Reporting Services), but the TFS security model takes on a very layered approach, where different permissions apply on different “levels”.

Most of the groups discussed below are configured and maintained in TFS, so where possible you would probably want to create Active Directory Groups and have these assigned to the correct TFS, SharePoint and Reporting Services groups. This allows you to assign and remove users from a single point (AD) and then this applies across the board.

Additionally TFS rights can be either “Allowed”, “Denied” or “Unset”. Unset means they are neither denied or allowed and means that the inheritance of that right from another group takes precedence. Also note that “Deny” takes precedence in most cases.

If you appear in two groups, one group allowing a feature and in another group that feature is denied, you will have that feature denied. The only exception is if you exist in an administrators group (“Project Administrators”, “Project Collection Administrators” or “Team Foundation Administrator”), the deny is overridden by the rights assignment in the administration group for the associated level.

Administration Console
This level is really assigned to individuals who are responsible for the administration of TFS itself. You cannot assign groups into this role (only users) and assigning this actually modifies rights on the physical aspects such the databases, SharePoint etc.
I would recommend that you limit the amount of users in this group to administrators responsible for TFS maintenance and high level configuration.
TFS Admin Console Assignment

Server Level Permissions
Focussed more at operational aspects of TFS on a server level and not specific to a project collections. These groups can only be modified from within the TFS Administration Console.
The default groups created at this level are:
  • SharePoint Web Application Services
  • Team Foundation Administrators
  • Team Foundation Service Accounts
  • Team Foundation Valid Users
  • Work Item Only View Users
This is where you assign permissions such as being able to create or delete project collections. The “Team Foundation Valid Users” and “Team Foundation Service Accounts” groups cannot be added to directly. The “Valid Users” group is an aggregated list of all the Server Level Permissions as well as the individual Project Collection “Valid Users” groups’ and merely assigns access to the TFS Web portal and viewing instance related information. The “Work Item Only View Users” is a group where you would typically assign project managers or the likes, that is only able to create and manage work items from the web portal, in other words you do not see build information and source code browser etc..
Permissions available on this level include:
  • Administer Warehouse
  • Create team project collection
  • Delete Team project collection
  • Edit instance-level information
  • Make requests on behalf of others
  • Use full Web Access features
  • View instance-level information

Collection Level Permissions
These are specific to the project collection. The reason for having this level is to segregate project collections from each other, providing something of a contained “eco-system” for each project collection. These can be modified from the TFS Administration Console as well as directly through Team Explorer.
The default groups created at this level are:
  • Project Collection Administrators
  • Project Collection Build Administrators
  • Project Collection Build Service Accounts
  • Project Collection Proxy Service Accounts
  • Project Collection Service Accounts
  • Project Collection Test Service Accounts
  • Project Collection Valid Users Collection 
As you can probably deduce from the names – these are still very much administration related groups, but as mentioned previously contained to a project collection.
Permissions available on this level include:
  • Administer shelved changes
  • Administer workspaces
  • Alter trace settings
  • Create a workspace
  • Create new projects
  • Delete team project
  • Edit collection-level information
  • Make requests on behalf of others
  • Manage build resources
  • Manage process template
  • Manage test controllers
  • Manage work item link types
  • Trigger Events
  • Use build resources
  • View build resources
  • View collection-level information
  • View system synchronization information
Project Level Permissions
This level is specific to a project and can only be managed through Team Explorer. This is also where things become interesting… setting permissions on this level, you need to consider the Build, Area’s, Iterations and Version Control, as each exhibits its own set of permissions. So to draw a comprehensive security model on this level you would need to draw together all the required permissions and then allocated the appropriate permissions in each of these functional areas. Once again if you have a large number of teams working on different projects, Active Directory Groups are definitely the way to go.
The number of default groups are small and include merely:
  • Builders
  • Contributors
  • Project Administrators
  • Readers
Areas and Iterations:
To my mind these are ways of grouping work. They are very similar in structure with only the permissions between the two differing. I quite like the description of having Areas denote the “logical, physical, or functional” grouping vs. Iterations that denote the time based grouping.
Right click on the project name in Team Explorer and select “Team Project Settings” then “Areas and Iterations”. This will display the dialog for managing the Areas and Iterations. At the bottom of the dialog next to the “Close” button you will find the “Security” button.
The permissions can be set at each node of the hierarchy and the permissions set at the lower nodes override the inherited permissions.
Permissions include:
Areas:
  • Create and order child nodes
  • Delete this node
  • Edit this node
  • Edit work items in this node
  • Manage test plans
  • View this node
  • View work items in this node
Note the work item permissions here. This allows you to “group” work items in the project and only allow certain users to “see” certain work items. This comes in handy when you subscribe to having a single project containing a number or individual projects.
Iterations
  • Create and order child nodes
  • Delete this node
  • Edit this node
  • View this node
Build
These permissions are specific to the build infrastructure that TFS provides. In Team Explorer under the appropriate project right click on the “Build” node and select “Security”.
Permissions available here are:
  • View builds
  • Edit build quality
  • Retain indefinitely
  • Delete builds
  • Manage build qualities
  • Destroy builds
  • Update build information
  • Queue build
  • Manage build queue
  • Stop builds
  • View build definition
  • Edit build definition
  • Delete build definition
  • Override check-in validation by build

Source Control
The version control repository where all files are checked into. Open the source control window by double clicking on “Source Control” node under the appropriate project. You should see the source control layout that looks similar to a folder structure. Right click on any of the “folders” select “Properties”. The dialog that is displayed will have a “Security” tab on. Note that if you have a folder marked as a branch the dialog looks different and the security functionality is under the “Permissions” tab. Similar to the Areas and Iterations the inherited permissions are overwritten.
Permissions available here are:
  • Read
  • Check out
  • Check in
  • Label
  • Lock
  • Revise other user's changes
  • Unlock other user's changes
  • Undo other user's changes
  • Administer labels
  • Manage permissions
  • Check in other user's changes
  • Merge
  • Manage branch

The TFS security model does give you a lot of flexibility, but it is not always that easy to navigate and manage. I have come across very few instances where there was a need to create additional groups within TFS, the default groups that are created are adequate for most deployments. If the need does arise to create custom groups, you should be aware of all the various aspects that it may encompass.