Cached TeamFoundationServer

Yesterday I have read Buck Hodges blog post on how to get instance of TeamFoundationServer. Getting TeamFoundationServer is the first thing one does when writing code that utilizes TFS Version Control object model, so naturally it is worth to know. Frankly, I did not think I will discover something new, but you live and you learn...

Two choices available are TeamFoundationServer class constructor or TeamFoundationServerFactory GetServer method. Buck covers the usage quite nicely in his post. The point of interest for me was that TeamFoundationServerFactory method will actually return same object in two different calls if given same URL as GetServer parameter.

That means if you use GetService method of returned TeamFoundationServer instance, it will essentially be the same service! So for example, if you retrieve VersionControlServer and hook up onto some event, you will need to do it only once; the second instance of TeamFoundationServer returned by factory will be the same and will return the same VersionControlServer with event handler set (below is pseudo code just to visualize the idea; no chance it will compile):

// first place
tfs1 = TeamFoundationServerFactory.GetServer(url);
vc1 = tfs1.GetService();
vc1.NewPendingChange += event1;
...
// second place
tfs2 = TeamFoundationServerFactory.GetServer(url);
vc2 = tfs2.GetService();
vc2.NewPendingChange += event1; // not required! already set

So that is something you'd want to keep in mind while writing your applications.

P.S. And some additional piece of wizdom from commentaries to the post:
"I recommend obtaining services from TFS OM for all services except the WorkItemStore. It is not thread safe, where as all other services you obtain from TFS OM are. To work around this issue, create a new WorkItemStore object and pass the credentials that you get from the TFS OM."
It is not official and I did not check that, but I love to assemble those bits of information. You never know when it may come in handy ...

Merging Visual Studio solutions

Recently, I have read a post in MSDN, and that reminded me of important issue I meant to raise for quite some time.
The scenario is rather simple - let us say that you branch folder that contain Visual Studio solution (or project); then you perform development in both branches. At some stage you merge one branch onto another.

While it is obvious how code files (C#, C++ etc.) are merged, for Visual Studio project and solution files it is less so. Even if you do not peform advanced changes in those files (for example, specifying different custom pre-/post- build steps), Visual Studio itself may change the file (see the problem is described in the post). And when you merge, usually there is no conflict and changes are merged automatically and thus you can end up with invalid solution or project file!

It appears there is no magic bullet solution for the issue in current version of TFS. What I do is essentially manual procedure: the idea is to check whether any solution/project files were merged. In most cases there are no conflicts to resolve, so I manually review the merged solution/project files before checking them in, to make sure that automatic merge changes make sense. It may be paranoid but is way better than broken solution.

More than that, after some thought on the subject, I do not see how it may be handled (aside from customized merge wizard specifically for Visual Studio solutions and projects). Any thoughts on the subject would be appreciated (I believe Microsoft guys will thank you as well).

Copying work items - hidden gotchas

Today I came across Eric Lee's post about copying work items. I also discovered this function quite accidentaly and have been happily using it for several months already.

So you right-click on selected Work Item in Query Results or on open Work Item, and click "Create Copy of Work Item..." - and voila! New item with identical data is displayed for you, so you can modify and save it. It allows one to avoid hassle of copying common fields or easily copy item to another project.

All goodness, but there are some not so obvious features within...

First, the newly created work item will be linked to the source work item (work item you copied a new work item from). If that is not your intention, and you do not glance on "Links" tab contents - you are in for surprise. And if you do that for some time then you have a whole lot of links. For example, if you have Item 1, then created Item 2 (by copying from Item 1) and then created Item 3 (by copying from Item 2) - now, how many linked items you will have in Item 3? You will have two - Item 1 and Item 2. That is surely a feature to be aware of (especially if you do not want to link those items)! I have discovered it only after I created the whole bunch of interlinked items...

Additionally, there is something very interesting in the history of the newly created work item. If you are creating items one after another (as in example above), all that information will be saved in history!

Here you can see copied work item history:


And here the first history entry expanded (and that is only a part of it):


Not that I care much about that information currently. It may be useful if you are trying to propagate bug through several Team projects (say bug found in "Project 1" will be copied to "Project 1.1" and then to "Project 1.2" - the data will be visible in history); but with current implementation of Team projects I doubt it is of much use. On the other hand, if you are copying items only for convenience, I do not see how that information is useful to anyone.

Those two I have discovered in a course of some two months of usage; but I will not be surprised if there are additional goodies in that function. And I wonder - what was the idea of the original author?