Adam Singer : Coding Practices

Ventriloquism: TFS Style

Adam Singer — Mon, 28 Jul 2008 18:45:00 GMT

Quite a long time back, Buck posted about how to recover from the situation where one TFS machine is created as a clone from another. This can lead to clients still showing the project list for one server when the connect to the second. Based on a recent Visual Studio Team System forums question (they certainly seem to be inspirational to me these days), I decided to code up a very simple tool that connects to one or more TFS instances and spits out their GUIDs so you can check whether they were cloned from each other. The actual interesting block of code is as follows:

TeamFoundationServer tfs = new TeamFoundationServer(arg);
Console.WriteLine("The GUID for server '{0}' is:{1} {2}",
arg, Environment.NewLine, tfs.InstanceId);

As you can see, there isn't much to finding out the GUID of a server. I've attached the project in case you want to play around with it yourself. Nothing fancy- I even attempted to manually hack it back to a Visual Studio 2008 capable csproj file since I'm using a recent internal version of the next release. Enjoy!

Random Acts of Group-ness

Adam Singer — Wed, 28 Feb 2007 22:00:00 GMT

Following up from my last post "'Grep'ing Groups" and this question on the forums, here's a bit of code that will help you add a user to multiple groups across all projects on your server. Say you want to add someone with the domain account "CORPNET\JoeBlogs" to the "Readers" group for all your projects on your Team Foundation Server "atlantis". Simply download, build, and run the attached code with the arguments "atlantis CORPNET\JoeBlogs Readers" as a Team Foundation Adminstrator.

A few of the more salient points in the code are as follows:

NTAccount userAccount = new NTAccount(username);
...
SecurityIdentifier userSid = (SecurityIdentifier)userAccount.Translate(typeof(SecurityIdentifier));

Here, I'm using some of the System.Security.Principal .NET helpers to conver our user to a SID. While I could also use the IGroupSecurityService's "ReadIdentityFromSource" call, that includes a round-trip to the server and includes a bit more information than we need in this helper code.

ProjectInfo[] projects = css.ListProjects();

Here, I chose to use "ListProjects()" rather than "ListAllProjects()". The former only includes well formed projects while the latter will list all projects that are in the process of being created, being deleted, etc. as well. In this case, I think we only want to try to update projects that have been completely constructed.

Identity projectGroup = gss.ReadIdentity(SearchFactor.AccountName, String.Format("[{0}]\\{1}", project.Name, groupToUpdate), QueryMembership.Expanded);
...
List<string> members = new List<string>(projectGroup.Members);
if (!members.Contains(userSid.ToString())) {...}

Before attempting to add the user to the group, I want to make sure it's not already a member. I chose to query the extended membership rather than just direct as it wouldn't make a difference in terms of user permissions whether the user is a direct member or a member under a nested group. However, if you want to make sure that the user is a direct member of the specified groups, you could change the "QueryMemberhip" value to Direct. Changing the query to Direct will also speed up the ReadIdentity call, particularly if your groups have many members.

Happy coding!

'Grep'ing Groups

Adam Singer — Fri, 09 Feb 2007 20:05:00 GMT

Man have I been busy. What have I been busy doing? Well, see there's.... actually, I'll let Brian explan as he's already done such an eloquent job at it, with some neat charts and graphs, too.

I mentioned in my last post that I have some code that will help you find built-in groups. It's actually pretty simple, and build upon code that James already provided last year. Say you want to find the Team Foundation Administrators group, the Valid Users group, or the Service Accounts group. These three groups are always created when TFS installs, so we added a neat flag to help you access them without knowing anything else than the server name. Try using the attached file as the main file in a new C# console application and then add dll references to Microsoft.TeamFoundation.dll, Microsoft.TeamFoundation.Client.dll, and Microsoft.TeamFoundation.Common.dll. Many thanks to Matt Hoover for the code review on my sample code here.

The key piece of code is the following method.

/// <summary>
/// Prints out the membership of the three built-in groups
/// </summary>
public void DisplayBuiltinGroupMembers()
{

// Find all the Administrative users
Identity adminUserSids = m_gss.ReadIdentity(SearchFactor.AdministrativeApplicationGroup, null, QueryMembership.Expanded);
PrintSubUsers(adminUserSids);

// Find all the Service accounts
Identity serviceSids = m_gss.ReadIdentity(SearchFactor.ServiceApplicationGroup, null, QueryMembership.Expanded);
PrintSubUsers(serviceSids);

// Find all the valid users
Identity allUserSids = m_gss.ReadIdentity(SearchFactor.EveryoneApplicationGroup, null, QueryMembership.Expanded);
PrintSubUsers(allUserSids);

}

We can also read the project administatrative groups in a similar way. The only thing you need to know is the project URI. Note that if you have the project name you can find its URI the ICommonStructureService's "GetProjectFromName" method.

ProjectInfo project = m_css.GetProjectFromName("My Project");
Identity adminGroup = m_gss.ReadIdentity(SearchFactor.AdministrativeApplicationGroup, project.Uri, QueryMembership.Expanded);

Disclaimers: The most efficient means of reading identity information is by using the SearchFactor.Sid. If you plan to do a tremendous number of queries like the ones in my sample app and want to get the best perf, this may not be the right method for you. Instead, use the members of the Microsoft.TeamFoundation.GroupWellKnownSidConstants class in Microsoft.TeamFoundation.Common.dll (this will also allow you to access the Licensed Users Group which only exists in the Team Foundation Server Workgroup Edition). Even so, the extra SearchFactors can make your code look a bit prettier.

New and Improved

Adam Singer — Thu, 14 Dec 2006 18:00:00 GMT

I always wondered about that phrase- "New and Improved". Either it's 'new', which means it never existed before, or it's 'improved' which means that it's better than the previous version(s) and, therefore, existed before. Finally I can stop wondering because I think I've come up with a situation where it can actually be logically applied.

Now that the first version of TFS (Team Foundation Server) is out in the wild doing its wild thing and we're well on the way in our hunt for version 2 we have a new issue to contend with. This issue is something that never came up in the last product cycle- Legacy Code. I'm talking about both product code and automated test code (of which we have a great deal).

The issue of course is that as we work, we learn. We come up with smarter, better, faster, stronger ways of doing whatever needs to be done. The old way still works, certainly, it's just not correct according to new preferred practices. In an ideal world, we'd like to refactor all of the code any time a new method comes into the shuffle. However, we only have so many hands and would like to release the next version some time this decade.

Given that, you have to make some tradeoffs and costing decisions. How bad does old code have to be before you update it? Certainly you'll update anything that gets broken, but do you apply all new practices, or just the critical ones? If it's bad enough, do you scrap it and start again?

In this sense, our automated test code is both new and improved. Some portions of it never existed before since the features tested didn't exist previously. Some portions of it have been upgraded to the new standards. And the third, unspoken, category is all that testcode from V1 that still does something useful, whether or not it's written the way we'd do it today.

I'd like to finish by posing a question to all you code writers out there- When what made your code tick just doesn't click, do you give it a kick, or just let it stick?