Team System

Subfolder overwrite issue in Team System RTM

We're having a strange problem with Team System, and we were hoping the RTM would fix it, but it didn't.

One of our projects relies heavily on generated code files. That means we frequently need to replace files in the solution with newer, regenerated versions of existing files.

This team has typically used drag and drop to place the new files in the solution. Unfortunately, we found out that drag and drop to subfolders, for files under Team System source control, has irrational behavior. I created an animated GIF movie to illustrate the problem in a fresh install of Team System RTM:

In the video, I drag and drop a new Class1.cs into to the /Subfolder directory in the solution, intended to overwrite the Class1.cs file that already exists in that folder. What happens is.. bizarre:

• \Subfolder\Class1.cs is overwritten with the new content but never checked out
  
• \Class1.cs is inexplicably checked out
  

I demo both drag and drop, and right click "Add file..". Both behave exactly the same way. We've tried a ton of different permutations, and the common factor seems to be overwriting files in a subfolder. If you drag into the root, or if you drag a new file into the solution, things work as you would expect.

This has caused a number of problems for the team. I hope some of our blog readers can duplicate this, and hopefully offer a solution or workaround!

minimum TFS and Team Explorer memory usage

I'm currently building up some virtual machines with the RTM  version of Team Foundation Server, and trying to determine the minimum amount of memory the server and client can run with. There's a basic set of planning guidelines at the Team System Developer Center..

100 members
Single Server -- 3.2 GHz, 1 GB

200 members
Single Server -- 3.2 GHz, 2 GB

400 members
Single Server -- dual 3.2 GHz, 2 GB

800 members
Application Tier -- 2.8 GHz, 1 GB
Data Tier -- dual 2.8 GHz, 4 GB

3500 members
Application Tier -- dual 2.8 GHz, 4 GB
Data Tier -- quad 2.8 GHz, 16 GB

.. but for the purposes of Team System Virtual PC testing, I wanted to see how low I could go.

I am using a single-server Team Foundation Server install-- which means the data tier (SQL Server 2005) and the application tier (Web Services, code logic) are on the same machine.

I tried to get the Team Foundation Server going with only 512 megabytes of memory first. Installation went fine, with some theoretical warnings about memory, but project creation failed with a timeout error. I bumped the memory up to 768 megabytes and all was well.

Here's a quick shot of Task Manager on the server (Windows Server 2003, R1) after creating a new Team System project and doing a few basic source control operations in the client:



That's with a user logged in at the desktop. Logging out would probably free up another 50 megabytes of memory. The commit charge is a bit high at 882 megabytes, but the available and system cache Physical Memory numbers look reasonable. The biggest consumer of memory on a single-server install is the SQL Server 2005 database. In this case it was consuming ~250 megabytes of memory all by itself. That may be a good argument in favor of a dual-server TFS install.

I set up a Windows XP client with 256 megabytes of memory. I did a basic install of Visual Studio 2005 pro, and then I installed the Team Explorer add-in from the Team Foundation Server media. Here's a screenshot of the client after creating a new project and doing a few basic source control operations:



This is mostly a measure of Visual Studio 2005's memory footprint, and a very trivial "Hello World" project at that. We have about 50 megabytes of headroom here, even with only 256 megabytes of memory. You may want to bump that up to 384 megabytes to accommodate more complex projects and/or advanced IDE features, but that should be plenty.

You can try everything I described above yourself using the Team Foundation Server 180-day Trial edition, which is now freely downloadable. Refer to Rob's install guide to see how it's done.  No Team System Edition of Visual Studio is required; plain old Visual Studio 2005 Pro or Standard will suffice!

Branching models vs. Pinning and Sharing

At SDWest, I picked up Seapine Software's whitepaper, Better Concurrent Development Through Branching. It has a great diagram of branching:



If, like me, you were weaned on Visual SourceSafe, you have a slightly distorted view of the world. As it turns out, SourceSafe's pinning and sharing functionality is a poor man's substitute for real branching, as Buck Hodges explains:

Branching and merging in TFS provide a more robust way to accomplish what sharing and pinning are often used for in VSS.  In TFS, you would branch a directory (source), using the "branch source target" command, to the desired location (target).  Then when there are changes in the source that you need in the target, you would use the "merge source target" command to propagate the changes.  The merge command remembers what changes have have been brought over to the target, so it brings the target up to date with the source by only merging changes that have not been merged.

The Seapine whitepaper references a SCM paper titled The Importance of Branching Models in SCM (pdf) which emphasizes that branching is the backbone of any modern source control system, and outlines some different approaches to branching along with the pros and cons of each.

Buck Hodges has another post where he outlines specificially how Team System is designed around branching:

• Path-space branching
  Branches are created within the path structure of the repository, similar to file copy operations. In talking to users, we find that this model is much easier to visualize, and is actually what they really want to do. They want a copy of the source that can evolve asynchronously and that's what we give them.
• Support for merging namespace changes
  Many SCC systems focus on merging content changes that have occurred to a specific file between 2 branches. We take a broader view of merging changes and focus on merging all types of changes between branches. Thus, we're able to merge file adds, deletes, moves, renames, etc. as part of your standard merge operation.
• Changesets
  Changes that are committed together are managed as a single entity called a changeset. Thus, when it comes time to merge a change to a new branch, you don't have to wrack your brain trying to figure out the full list of files you need to operate on. Just tell us which changeset you want to merge and we'll do it all for you.
• Cherry-pick merges
  You can merge specific file change to another branch without merging the changes that were included in previous versions of those files. Thus, if you've got 2 bug fixes which touch the same file, you can merge the second one without merging the first.
• Merge candidate queries
  You can ask the system for a list of all changes which haven't yet been merged between 2 branches.
• Merge history queries
  You can ask the system for a list of all changes that have ever been merged between 2 branches.

Buck notes that the VSTS team is partial to the Branch by Purpose model, which is outlined in the SCM paper:



If you're adapting to Team System, you'll definitely want to develop with branching in mind.

Team Test and the Load Test Agent

A customer recently asked: how many users can I simulate using a single copy of Team Edition for Testers?

While you can do some ad-hoc testing using a desktop install of Team Edition for Testers or Team Suite, if you want to simulate large numbers of users, you need to install the Load Test Agent and Load Test Controller. These are standalone components designed to run on a farm of machines. You connect to and control them with Visual Studio, via the Test, Administer Test Controllers menu:



Microsoft provides some rules of thumb for the number of users you can simulate using the agent and controller, which I have summarized and grouped here. The recommended machine specs are are provided in the order of CPU speed, memory, and disk space, respectively.

for 1-2 projects, 5-20 users:

agent	600 MHz	256 MB	1 GB
controller	600 MHz	256 MB	1 GB
both	600 MHz	512 MB	1 GB

for 2-20 projects, 20-100 users:

agent	2.0 GHz	512 MB	5 GB
controller	1.0 GHz	512 MB	8 GB
both	2.0 GHz	1 GB	8 GB

for 20+ projects, 100-250 users:

agent	2.6 GHz	2 GB	5 GB
controller	2.0 GHz	1 GB	40 GB
both	2.6 GHz	2 GB	40 GB

for 50+ projects, 250-500 users:

agent	2.8 GHz dual	2 GB	8 GB
controller	2.6 GHz	1 GB	48 GB
both	2.8 GHz dual	2 GB	48 GB

Ed Glas has an outstanding, highly detailed overview of the all different things you need to consider when setting up a farm of load agents.

One frequent point of confusion is that the Team Test Load Agent is licensed seperately. If you want to set up a farm of five machines running the Load Agent, you need five licenses.  And this license is not cheap, as you can see on the Team System licensing page: it's currently $5,089 per!

Using Team System source control with Visual Studio .NET 2003

The VSTS team recently released a beta MSSCCI (Microsoft Source Code Control Interface) provider for Team System -- now you can use Team System source control in any application that supports the SCCI interfaces!

Unfortunately, I didn't have any luck getting the provider to work with Beyond Compare, which supports SCCI interfaces in version 2.4. But the primary audience for this provider is Visual Studio .NET 2003 and Visual Studio 6. And it definitely works in VS.NET 2003.

One unfortunate limitation of the beta version of the provider, however, is that you need to run a special registry file to disable strong name validation for its assemblies before it will run without crashing. You can download a copy of this registry file from us in case you need it.

Once you fix up the registry, the VSTS SCCI provider works great in Visual Studio .NET 2003 .. with one caveat. Visual Studio 2003, unlike 2005, does not allow you to switch between SCCI providers. I recommend using Soenke Schau's Sourcecode Control Switcher app, which provides the missing SCCI switching functionality:



Now you can choose between SourceSafe, VSTS, and any other third party source code control providers with ease in Visual Studio .NET 2003. I think you have to exit and restart the IDE between switches, though.

Once the VSTS MSSCCI provider was installed, I created a new console application in Visual Studio .NET 2003, then right clicked the project and selected Add to Source Control:



Then I'm prompted for the Team System server I wish to connect to.



Once I connect, I select a VSTS source folder to store the project in. I'm choosing the root here:



From here on out, it behaves nearly identically to SourceSafe, at least in terms of IDE integration. Here's the source control menu for the main class of the console app:



It may look familiar, but this is VSTS source control, which means it's worlds better than ye olde SourceSafe. For one thing, as you can see in the source control options, it now defaults to shared checkouts:

Simple Load Testing with Team Test Edition

In my previous post, we set up a simple web test using VSTS test functionality. Let's turn that web test into a load test.

First, add a new load test to our existing test project via the File, Add, New Project menu:



Adding the load test kicks off the load test wizard. Everything can be specified manually if you aren't into the whole wizard thing, but it's helpful to step through it at least once to get an idea of the options that are available.

Step 1: Select a name and a think time profile:



Step 2: Select between constant and step load patterns:



Step 3: Add a test. We only have one test in our existing test project, so this one is a no-brainer.



Step 4: Select the browser type and distributions. I chose something reasonable based on current market browser distributions.



Step 5: Select counters to monitor. The default counter sets are usually plenty, but you might want more detail.



Step 6: Select the pool of network connections and the distributions. I'm assuming most people are on broadband by now, but we might want to throw in a small fraction of dialup users, too.



Step 7: Set durations and sampling rate. I made this a brief two minute test.



Once you complete the wizard, you'll see the load test show up in your test project, and it will reflect all the choices you made in the wizard:



Launch the load test by clicking the green run button, and you'll see the stats gathered in real time in a new results window:



The really neat thing about this window is that it's "live". Unfortunately that isn't communicated well in this static screenshot. But you can see all the data paint in as it's collected-- and you can add and remove counters in the graph, too. It's nice to get an idea of whether your load test is doing what you wanted or not, before waiting an hour to see the final results!

Simple Web Testing with Team Test Edition

Team System's web testing functionality is, in my opinion, one of the strongest features in any of the Team System Editions. The web test functionality is only included in Team Test Edition and, of course, Team Suite-- which has everything.

Here's how easy it is to create a basic web test. First, add a test project to your solution via File, New, Project, Web Test:



The new test project will show up in your solution, and your first empty web test will be open by default:



At this point you would typically launch the web recorder, which is based on an IE plugin. You can do that by clicking the red "record" button on the toolbar, or right clicking and selecting Add Recording.



I'm recording a simple little web site that echoes back whatever we typed in a label with "Hello, " prefixed. This is why I make the big bucks as a professional developer, people!

Once I've completed the recording, the recorded HTTP transactions will show up in the web test. One request, one post:



Let's make this a real web test by right clicking and adding a validation rule to the second step, the post:



We'll check the results for the string "Hello, Cleveland!". Now that we've added our validation rule and made this a bona-fide test, click the run button on the toolbar to run it:



Woo-hoo! We passed!

Of course, I'm barely scratching the surface of what you can do here, but it's pleasingly simple to get a basic test up and running. And that's one less excuse for not having web tests on your web project.

What is Visual Studio 2005 Premier Partner Edition?

After you install Team Foundation Server, you may notice that something unusual appears in your server's Add or Remove Programs dialog:



What the heck is Visual Studio 2005 Premier Partner Edition?

Evidently the "Partner Edition" is a minimalist, shell install of Visual Studio 2005 with only the core Team System Functionality. In fact, it's the only obvious way to interact with Team System on the server, as you can see from the server's Start Menu:



If you launch this, it will look exactly like Visual Studio 2005, but ..

• it's missing about half the menus of a typical VS 2005 install
• it has all the Team System functionality

The About dialog makes it a little more clear what is happening here:



Well, at least we have the Team Explorer installed!

You won't be building any C# console apps with this version of Visual Studio, because it's been gutted. This Visual Studio 2005 install is only intended as a management tool for your Team Foundation Server.

Adding a new Work Item type to a Project

For one of our projects, we wanted to add a new work item type for user feedback. The standard work items in the default Microsoft Agile process template are:

• Bug
• Quality of Service Requirement
  
• Risk
• Scenario
• Task

You can add these work items from the Team menu, or by right-clicking the Work Items project node in the Team Explorer:



In order to add a new work item template, however, you need to obtain the process template. You can do this via the Team, Team Foundation Server Settings, Process Template Manager dialog:



Note that you will need "Edit domain-level information" permissions to upload or download anything here. If the buttons are greyed out, that's why!

Download the template to any path you like. It's just a bunch of files. Once you download the template files, navigate to the folder \WorkItem Tracking\TypeDefinitions:



Make a copy of whichever work item template is closest to your needs. In our case, it's Risk.xml.



I modified this copy slightly by changing all the descriptions to "User Feedback". Other than that simple textual change, it's identical to a Risk.

We can use the command-line utility witimport.exe to import this work item template file to our target project. It's with all the other TFS command line utils in the c:\program files\Microsoft Visual Studio 8\Common7\IDE folder:

Imports a work item type XML definition file into a Team Project on a Team
Foundation Server.  The imported definition will overwrite any existing work
item type with the same name.  If the work item type does not already exist,
a new work item type will be created.

Use:

witimport /f filename /t tfs /p teamproject [/v] [/e encodingname]

/f        Specifies the work item type XML definition file to be imported.
/t        Specifies the name of the Team Foundation Server. This can also be a
          fully specified URL such as http://tfs:8181.
/p        Specifies the Team Project on the Team Foundation Server to which the
          file is imported.
/v        Validates the XML without importing the work item type.
/e        Specifies the name of the .NET Framework 2.0 encoding used to import
          the work item type XML.  For example, /e utf-7 will use Unicode
          (UTF-7) encoding.  Encoding is auto-detected by default where
          possible.  If unavailable, encoding defaults to UTF-8.

Once we've imported our work item template file, we can re-open our Team Project and successfully add a new work item of type "User Feedback":

Now if only I could figure out how to delete a work item template..

TestDriven.NET works with VSTS unit testing

I just found out that TestDriven.NET supports Visual Studio Team System's flavor of unit testing from Brian Button's blog.

Check out the install dialog:



How cool is that? The TestDriven.NET integration addresses one of the criticisms of VSTS unit testing, specifically, that too many actions are only possible from the Test IDE windows (Test View, Test Results, Code Coverage Results, and Test Runs):



With TestDriven.NET installed, now you can..

1) run a VSTS unit test directly from the source code (with code coverage!)



2) double-click a failed test's stack trace to jump to the relevant code:



The test output appears in the output window instead of the Test Results window, but that's a minor nit.

Why VSTS unit testing didn't include this simple and highly useful functionality out of the box, I have no idea, but my hat is off to Jamie Cansdale!

 

Requiring unit tests prior to check-in

Yet another question that came up during our Team System migration was

How do we require developers to check in code that has passed all unit tests?

Another perfectly reasonable request. Unit tests can't help you if you aren't using them. Requiring developers to pass unit tests before checking code in is always a good idea.

There is an existing Testing Policy that should work great for this, right? Well, let's try adding it..

1. Right click the project in Team Explorer
2. Click Team Project Settings
3. Click Source Control
4. Click the Check-in Policy tab
5. Click Add
6. Select Testing Policy
7. Click Browse

The test Metadata File (*.vsdmi) it's asking for is created under the Solution Items folder when you create unit tests. This file will be under source control, so browse to the project and locate that file.

After I selected the file, I was greeted with this error message: This Metadata file has zero test lists. Please choose one containing at least one unit test.



The Test Policy requires a test list. Unfortunately, the Developer edition of Team System (what we're all using here at Vertigo) cannot create test lists. This is a case where the role-based editions really bite us! I'm also left wondering why there isn't a default "all tests" list of some kind, but that's a discussion for another post.

In order to create a test list, we need Test Edition or Team Suite. Luckily I have Test Edition in a VM, so I created a test list in the Test Manager:



I only put one unit test (ExpandPathTest) in this particular list (Sample) for simplicity's sake. Now that I have a test list, I can finally create the policy:



Once you do this, you'll get the expected policy failure if you try to check in code and you haven't run the unit tests.



Note that the check-in process will not run the unit tests for you. You must do a build, then run the tests via the Test View window prior to the checkin.



Oops, I did it again! Let's fix the offending code. Then I build the solution, and re-run this test..



Now I can check in without any policy warnings. Just remember, this policy warns about two things:

1. If you haven't run the unit tests at all
2. If your unit tests have errors

If either of those things is true, it's a check-in policy violation.