I’ve been meaning to set up a TFS install at home for some time. Up to now, I’ve been running TFS Beta 3 Refresh in a Virtual Machine, but it was on a borrowed box and came with the bits pre-installed. Other issues were that it was configured as a domain controller and although it played nicely with my network, it couldn’t be a member of my home domain without some serious reconfiguration. Finally, I wanted to go through the install process again to see how much better it had got since Beta 3 (hint: the answer is “a lot!”)
I had a look at the recommended system configurations for TFS and decided that, as it’s mainly going to be only me accessing this box I probably fall into the “Small Team”category. I wanted a box that’d fit in my rack (and not take up too much space so that I didn’t have to move my stereo out of there). Dell have a couple of great 1 RU servers so I convinced the CFO that we really needed to invest in a PoweEdge 850. I went for a PentiumD chip but pretty much min specs on all the rest (it’s probably going to be easier to add HDD and RAM than do a processor upgrade later).
I run Small Business Server at home (my wife finds it easiest to schedule time with me if our calendars can talk, so Exchange is sensational). Adding another server to the domain is fine. In fact, Mark Stanfil has just blogged about Two New White Papers for SBS - Multiple Servers on The Official SBS Support Blog.
Installing the box was painless. The Dell units are really nicely engineered, no mucking around with cage nuts etc in the rack. In addition, even I can manhandle a 1 RU server without too much trouble. The engineering really shows in the little things. Opening up the box shows that even though I only got 1 SATA drive pre-installed, the cage for another was there, with all of the cabling (power and SATA) terminating just behind that. The only small complaint I have is that the folks who assembled the box had their torque setting too high on the screwdriver, so the “toolless thumbscrews” weren’t.
On to the install process. Win2k3 Standard with SP1 is simple, Next, Next, Next … Grabbed all of the critical updates.
Now for the TFS itself. There’s a great step-by-step guide and the install process has become almost completely painless. I’d love to see this completely wizard-driven – at the moment it’s a series of manual steps, but the instructions are very comprehensive.
Once I had done all of the install steps (about 4 hours total I think), including the Team Explorer client on the TFS box, I created a team project. Hey, it just worked!
I installed the new Team Explorer client on my dev box and connected to the server. Again, it just worked!
I did the survey and sent in my install logs, but there’s probably not much to gain from them – “Nothing to see here. Move along.”
Next steps for me:
Rob Caron (and a number of other folk) blogged yesterday that the next release of the Visual Studio Team Foundation Server MSSCCI Provider has been posted. This is great news for people using VS2003, VS2002, VS6, SQL Server Enterprise Manager, or any other IDE that supports the MSSCCI Source Control API.
In particular, for me this is great news because I can now use TFS as my SCC provider for my VFP projects (as opposed to the Beta 1 experience). I’ve recently set up a TFS server in my home office, so connecting to is from VFP has been a priority.
The reason for the asterisk in the title of this post is that there's one important thing the download page doesn’t tell you. The Beta 2 binaries are not strongly named, so attempting to use the plugin as it is results in an error: "TFMscciSvr.exe has encountered a problem and needs to close. We are sorry for the inconvenience" (this isn't restricted to VFP BTW).
Buck Hodges has posted a work-around for this. Basically you need to disable strong name validation (for these assemblies only). Copy the following text into a .reg file and execute it (remembering that it is your registry and that you should back it up before you do anything to it).
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\StrongName\Verification\Microsoft.TeamFoundation.Msscci,B03F5F7F11D50A3A] [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\StrongName\Verification\Microsoft.TeamFoundation.VersionControl.Controls,B03F5F7F11D50A3A] [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\StrongName\Verification\Microsoft.TeamFoundation.WorkItemTracking.Controls,B03F5F7F11D50A3A] [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\StrongName\Verification\Microsoft.VisualStudio.TeamFoundation.WorkItemTracking,B03F5F7F11D50A3A] [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\StrongName\Verification\TFMscciGui,B03F5F7F11D50A3A] [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\StrongName\Verification\TFMscciSvr,B03F5F7F11D50A3A]
Running this will disable the Strong Name Verification for assemblies with the hash values listed. Now you can choose the MSSCCI TFS provider in the Source Code Plugin Selection Drop Down on the Projects tab of VFP's options dialog.
Note that you'll need to create your project from a Team Explorer, but once it's created you can interact with it happily from VFP.
When the MSSCCI Provider for Team Foundation Server was announced, I was very excited. VFP (like the VS6 IDE, VS2002 and VS2003 as well as many other IDEs such as SQL Enterprise Manager) has the ability to utilise a MSSCCI compliant Source Control provider. The one most commonly used for VFP is Visual Source Safe, but I really wanted to hook into some of the great new features of TFS’s enterprise Source Control capabilities.
I was a little disappointed to discover that the preview version released late last year had a problem that precluded its use with VFP (C0000005 error anyone?). Of course, I reported this back up to the product teams (VFP and TFS) and was happy to hear back today that the problem’s been fixed and everything should be fine in the beta due to be released in the next week or so.