Root for the migration cause

Have you ever written a post or asked a question about migration paths to TFS from SVN, StarTeam etc.? Do you know someone who did?

Well, now it still may be not too late to head to CodePlex and vote for the migration you have been longing for. And no excuses! If you sum up all votes and compare them with number of questions "How can I migrate [smth] to TFS" the vote count is still short of couple of hundred votes.

Thanks to Martin Woodward for highlighting the voting in progress. I read about it and then forgot, but now I went there and voted. Did you?

Not only VS 2008 got released

Aw right, VS 2008 Beta 2 was released as you probably heard by now. The blogsphere is awash with VS-related posts, but this one is not about it :)

One for TFS guys - if you do Work Items customizations, have a look at custom WorkItem Date Picker control by Paul Hacker. It allows you to have a date picker control in a work item instead of free form text input which is provided by default. And if you find it handy or find it lacking something or have a great idea for custom control, do drop a line to Paul. In my opinion, we should have by now a library of custom controls, verified and ready to deploy, but we still do not and this one is great start!

Another for MSBuild guys - if you find yourself writing a lot of MSBuild in VS, Stuart Preston created a useful-looking VS MSBuild project template for you. Now you can have MSBuild project on a par with C# and C++ projects in VS!

And going back to Visual Studio - version 2.0 of Web Access for TFS is available (called now Team System Web Access Power Tool)!

(I think I had managed to fill this one with exclamation marks!)

Adding TFS-related commands in VSIP package

If you want to extend Team Foundation Visual Studio integration, the easiest way would be to write an add-in using VS automation. Alternatively, you may want to develop full-blown integration package; while it gives you much more flexibility, thing also become more complicated.

One of the differences is the way to add commands/menus. In VS package implementation you would use CTC (Command Table Compiler) file for that, and you will be required to know the GUID:ID pairs for the parent menus when adding your custom commands. And getting this information might take some do, especially for Team Foundation related menus!

Obvioulsy, firts thing is to browse through the header files included in VS 2005 SDK. But the thing is that the GUID:ID information for Source Control Explorer/Work Items menus is not located with the rest of similar IDs in stdidcmd.h/vsshlids.h headers, or other headers in Include folder.
But never give up! There are two additional headers, TFS_VC_IDs.h file located under Program Files\Visual Studio 2005 SDK\2007.02\VisualStudioTeamSystemIntegration\Version Control folder and containing version control related menu and command IDs, and TFS_WIT_IDs.h file located under Program Files\Visual Studio 2005 SDK\2007.02\VisualStudioTeamSystemIntegration\Work Item Tracking folder and containing work item related IDs. Great thanks to Chad Boles@Microsoft for the info!

Interesting thing is, that the information is available on WWW - but I'll be darned if I could google that (and I am pretty good at that too)! So here it goes - there is a post in Brian Keller's blog that mentions those headers. Do you think you could find that?

And in conclusion, couple of more related links. If you have troubles looking up GUID:ID pairs for CTC definitions (which easily could be the case if you are trying to extend custom packages), the technique described in the following Martin Tracy's blog post may be very useful. In fact, using that approach I got the IDs right before getting the official answer :)

And if you want to understand CTC better, this here post supplies lots of useful details on how to create bare-bones CTC without headers and pre-compiler.

.NET Update gets in the way of TFS

If you have installed (automatically through Windows Update or manually) an update for .Net 2.0, you now may encounter issues connecting to TFS as described in Michael Ruminer's blog post. But no worries, there is an easy way out for you!
The post suggested that you uninstall the update, but fortunately as I started on uninstalling it I have read the comments to the post.
Buck Hodges commented: "If you hit this, simply turn off client-side tracing that you or someone else previously enabled (e.g., in devenv.exe.config), since it's not on by default."
And indeed, editing devenv.exe.config worked like a charm for me. Beats uninistalling things, doesn't it?
Thanks guys for making the solution available at such short notice!

Maximum size of the file under source control (continued)

In my previous post I wrote about the deltas mechanim used to store files revisions in TFS database and (somewhat) lamented the lack of configuration and documentation of that.

Well, it seems that at least configuration is taken care of. As Richard Berg helpfully pointed out in the comments to the post, it is possible to specify "deltaMaxFileSize" parameter in web.config file of Version Control web service (for default installation located in C:\Program Files\Microsoft Visual Studio 2005 Team Foundation Server\Web Services\VersionControl).
The value of this key is maximum file size (in bytes) to perform delta algorithm on. For example, the following setting will be equivalent to default (16 Mb size):

    <add key="deltaMaxFileSize" value="16777216" />

I did play around with that setting a bit; I created a ZIP file full of small 1 Kb sized files and put it through check-out/check-in cycle removing single file from archive for each new revision. The database size was gauged using SQL Server Management studio to view properties of TfsVersionControl database. The setting did work as expected, and reverse delta algorithm indeed works amazingly well - with delta enabled the database size remained effectively constant when I added a new revisions of the file.

So as it turned out, you can optionally configure the algorithm; I'd say it is something to do if you contemplate storing revisions of large binary files. A word of caution though - as the setting is yet to find the way into official documentation on TFS, it is not supported at the moment.

Update: Important remark (courtesy of Buck Hodges) on side effects of changing the default value: "You'll also want to think really hard about setting the value any larger. The library that does this doesn't consume memory linearly (it's CPU intensive as well). It's not hard to run your server out of memory when you least expect it."

Thanks for the award

On Sunday I got an email with Microsoft Visual Studio Team System MVP award inside. Wow! What can I say - I am overjoyed to join the ranks of esteemed and respected Team System MVPs (many of whom I had a pleasure to be acquainted with either in person or virtually). I hope to be worthy of the group and will continue to participate in TFS community (and perhaps now with all additional resources available to MVPs I will be able to give better answers, too!).

Using the occasion I'd like to congratulate another newly awarded Team System MVP, Steve St. Jean. Many a time I came across his blog while browsing WWW for an answer on intricacies of Team Build. Congratulations Steve!

Thanks everyone who helped me in getting there!

Maximum size of the file under source control - should you care?

In this forum thread I came across very interesting piece of information that I feel might be interesting to the community at large.

Probably anyone using source control application asked that question at some stage - what happens if I check in 500Mb disk image file? For some source control systems (f.e. VSS) the answer is relatively simple - you'd end up increasing your DB size by approximately 500 Mb every time you check in new revision of the file.
However, for TFS only deltas between the revisions will be saved, so your database will not become bloated if you store several versions of that huge binary file. Or so I thought - because it turned out that deltas mechanism is used only for the files that are smaller than 16 Mb. May be that's just me, but that number eluded me in the original documentation on MSDN and I was under the impression that if someone maintains several revisions of huge binary file it is not a big deal.

But in reality, that can well create a problem. In v 1.0 of TFS there is no permanent destroy, so if one created twenty revisions of CD image that will immediately affect your database size, and there is no way back!

The reason for this (conveniently explained by Richard Berg in the forum thread) is understandable - indeed, calculating deltas for large files can adversely affect server performance, and therefore it is disabled. But I am not sure that I like the way it is not specified in official documentation and not configurable on server.

Obvious way of making sure that your database is not affected by those binary files is not to store them in TFS at all (and create maximum file size check in policy to enforce the file sizes). Or if you do store them, store only one revision and use branches if you need to reference this file. While both approaches take some additional effort for policies enforcement and user education, at least now you can make sure you can explain that sudden increase in database size. Look for new revisions of those large files :)

TFS ripoff or back up your money (updated)

Today I come across pretty interesting post on MSDN forums. To give your some background: recently (about a month ago) some company started to market suite of products that supposedly perform migration from SVN to TFS, backup of TFS projects, work items etc.

The inability to backup separate projects has long plagued TFS community; the company was mentioned in several blogs and in several MSDN postings. I was saying to myself "Kudos to those guys for doing that enormous work and implementing functionality even MS itself was unable to implement". Until today somebody (apparently the buyer of the said software) posted the following:

"... is a fraud company. I had purchased one of their products. The buggers provided me a *** software, which was good for nothing. I have even heard from a mate of mine in France that they charged the product amount and never gave the product.

Today - Even their website does not work."

Well, that surely sets off some alarms. So I indulged a bit in some hobbyist investigation and here goes the list of interesting facts:

1. The company site is offline as of now; the domain was registered on April 19th, 2007, shortly before the first mention of the products offered appeared.


2. Neither pricing information nor trial downloads of the products were available at the site (the site is only available now through Google cache).


3. All posts pointing to the company site on MSDN forums were posted by the same user "gauravmangla". Looking at activity of the user one may see that user was registered on May, 2nd 2007 and all his postings are linking to the mentioned company site. No other posts by the same user are found.


4. The only feedback posts on MSDN forums is by some user named "john.matthews01", registered on May, 26th 2007 and whose three posts are concerned solely with praise to the company software. No other posts by the same user are found.


5. No customer feedback from real customers is found using Google (I mean feedback from real-life person non-affilated with the company); only mention of the software in TFS related blogs.

Before I compiled that short list, I was inclined to think that the company in question is new micro-ISV company (of the kind regularily discussed at JoelOnSoftware forums), perhaps with very decent offering that help lost of people in TFS crowd; but now I am of opinion that some fraud scenario might have been at work. My conclusions from that story - before buying something

• Download trial version; if no trial is available then reconsider


• Request client reference/search for users feedback; if none found then reconsider


• If the company is new and the price of the software is significant for you, reconsider


• Use credit card to pay for the software to make sure you get your money back in case of fraud

Update: I stand corrected as the owner of the company in question posted an explanation of the situation; the site is inavailable due to some internal problems ("... a disgruntled employee left our company and he was responsible for our web site. He changed all the passwords and removed all the web site code"); no products was shipped so far due to export limitations so the rumours of products beind paid for and not shipped appear to be just rumours without any solid foundation.
I do hope the company will be able to resolve the internal situation and resume business as usual.

Move caveats (I like to move it move it ... not)

Recent post on MSDN forums reminded me of an important issue in TFS Move functionality.

To give you a short summary - you move file (or more frequently a folder) within your source code repository using TFS Move command. The sky is blue, everything works all right - until at some later point you decide to retrieve the item version before move changes. Then in VS GUI you will receive an error; nothing you do will get you that version using UI. Only possible workaround is to use tf command line get with an old item name/path specified and versionspec before move.

While for most of us it is hardly a show stopper, think about a scenario when you move a whole team project subtree (that's what the author of the original forum post did). If you interested in previous revisions in that setup - that might be pretty cumbersome.

I do not judge the implementation of that; in my opinion you can argue successfully both ways (bug vs logical implementation). But it is certainly the fact to be aware of before you check in the results of your latest move operation.

TFS local cache: servers, workspaces and more!

Interesting part of TFS object model deals with locally cached information. Using that API you may iterate over local workspaces, determine whether specific path is mapped and even find out TFS server location URI. I have touched upon it in the previous post, but recently related question was raised in forums again; so it appears that the topic is ripe for some additional clarification.

The journey into cached information starts with Workstation class (that and other relevant classes are part of Microsoft.TeamFoundation.VersionControl.Client assembly). This singleton class exposes static Current property which returns Workstation object for the current computer. The class exposes several methods of interest, for example IsMapped method allows you to detemine if specific path is mapped in some workspace.

In my opinion, most valuable method is GetAllLocalWorkspaceInfo. As follows from its name, it returns set of WorkspaceInfo objects that comprise the local workspace cache.
Using WorkspaceInfo class you may perform several useful tasks:

• Obtain TFS server URL by using ServerUri property; that may come in handy if you do not have the server URI and do not want to force user to specify it


• Retrieve Workspace object using GetWorkspace(WorkspaceInfo workspace) method of VersionControlServer or GetWorkspace(TeamFoundationServer) method of WorkspaceInfo object itself; from that point on it will be possible to perform usual version control related operations


• Use WorkspaceInfo properties to view local workspace information without connecting to TFS server

While usually the location of TFS server is known and one may use QueryWorkspaces method to get list of workspaces, the approach described above will help you out in cases where one needs to find out TFS server locations or obtain information about local workspaces without setting up a connection to server.

And to conclude, another convenient way to retrieve list of server URIs would be to use GetServers method of RegisteredServers class. It will return the list of all server locations stored in registry (the list that appears in "Connect to TFS Server" window).