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!