Using SourceSafe & Visual Studio .NET in a Team Environment

Now back to the public service part of our show.

Caller: I work on a large team. Are there any rules I should follow to ensure that we do not step on each other while building software if we are using SourceSafe?

Greg: Great question caller. Having worked with people who stepped all over me, I understand the tread avoidance. Let’s talk about some rules for SourceSafe that will make your life easier.

Rule #1: If you end up with a website or web service that will not run correctly, do not chagne it to run as a class library.

Yeah, I know this is fairly obvious, but so is "do not point soda bottle at your eye" and "do not use hairdryer in the bathtub" but both of those are on these objects for very good reason, namely somebody did it.

SourceSafe is a pain. I know it! You know it! But, it is a manageable pain as long as nobody goes off rogue and kludges the process. If you end up with a project that will not run as a website when you get the code from SourceSafe, try the following first.

  1. Make sure you have the website folder set up as a directory under IIS (does not apply to folder based webs in ASP.NET 2.0, of course). You have to name this site set up with the same name as is in the .webinfo file. If you had a sane developer who originally set up the project, it usually ferrets out like this.
    1. Project is named MySuperCoolWebSite
    2. URL is http://localhost/MySuperCoolWebSite
    3. IIS virtual directory is MySuperCoolWebSite

      See how sane that is.
      As an aside: You should not name the website. MyCompanyNamespace.MainProjectNamespace.ParticularWebsiteNamespace.Website – that would be stupid

  2. If you still cannot connect in Visual Studio, you can go to IIS and make the site browsable and then Add >> Existing Project from Web in the Solution Explorer right click member. Another option, almost as easy, is this:
    1. Right click in Solution Explorer >> Add >> Existing Project from Web
    2. Type in local URL: http://localhost/MySuperCoolWebSite – NTOE TO SELF: will have to cover ASP.NET 2.0 folder based webs in a future episode
    3. Type in path to the csproj or vbproj file.
      C#: http://localhost/MySuperCoolWebSite/

      VB: http://localhost/MySuperCoolWebSite/

      NOTE: SourceSafe may complain about not having access. Just tell it "yes" (which equates to Shut Up!) and you will be fine. Yes, SourceSafe will still work properly.

Rule #2: Do not point multiple source tree locations to the same physical file location.

This should also be obvious, but just in case it is not, let me explain a couple of issues:

  • It can break locations in IIS; you have to really work at this one, but trust me, I have seen it done
  • You can end up overwriting with the wrong source
  • It is really confusing to the person trying to demunge your crap

Just don’t do it.

Rule #3: Do not leave organizational units checked out.

This brings up two questions

What are organizational units? Solution files and project files.

Why should I not keep them checked out? Yo dog, I know you think your s**t is more important than everyone else in the world, but we need to add some files too. Other potential problems, that relate to other rules, of course.

  • If you check in files in other projects that reference these magic files, my build breaks
  • If you check in the project while you are still in the process of editing the file, my build breaks
  • If you leave for vacation, my build is broken until you decide to stop sipping umbrella drinks in the Dominican Republic.

Best practice: If you need to add to an organizational unit, like a project, add file(s), check new stub and organizational unit in IMMEDIATELY. That will NOT break my build. Got it? Good!

Rule #4: Treat a work unit as a unit when you check in.

Checking in a single file at a time causes major problems. Yes, those little red items in Cruise Control .NET are yours.

Rule #5: Work on one item at a time and finish.

I know that you are the master at multi-tasking, but the number of times you broke my build prove you have an error in your processor core. Perhaps single-tasking is more efficient.

Well folks, that is about all the time I have for today. I want to thank all of the callers who did not get their question answered. I will attempt to pick up on those questions some time next week. On our next show we will cover "User Controls as black boxes, creating controls that don’t suck!".

Team System

After my first blog entry, I have had many questions about Team System. Please note that I am an MVP, NOT a Microsoft employee, so I am working on information from public sources, as well as asking some questions behind the scenes. This post, along with my previous post, combine the best information I know to date.

Question 1: What comes with each Team System product?

Each Team System product comes with (above Professional)

  • Tools described below
  • CAL for Team Foundation Server – $499 per seat for non Team System SKUs and additional non-Team System users

Team Architect – Architecture tools (no cost upgrade until current license expires, $2299 retail/year renewal)

  • Application Designer – Logical design of the application, will stub in classes
  • Infrastructure Designer – Diagram of physical machines (and clusters)
  • Deployment Designer – Marries application with infrastructure and validates deployment
  • Class Designer – Tool to design classes in .NET projects

Team Developer – Development Tools (no cost upgrade until current license expires, $2299 retail/year renewal)

  • Class Designer – Tool to design classes in .NET projects
  • Unit Testing Tools – allows for Test Driven Development
  • Code Coverage Tools – Ensures tests are written for all code
  • Code Analysis Tools – Code quality metrics
    • Static
    • Dynamic
  • Code Profiler

Team Tester – Testing (no cost upgrade until current license expires, $2299 retail/year renewal)

  • Unit Testing Tools – allows for Test Driven Development
  • Code Coverage Tools – Ensures tests are written for all code
  • Test Case Management – Manages different types of tests (below)
  • Web Testing – Record, customize and run
  • Load Testing – Basic load testing with the product (not sure how many virtual users out of box – ACTION ITEM); can buy additional load test agents (below)

Team Suite ($3499/year renewal; $1200 upgrade over free Team System upgrade (above))

  • All of the tools in the other Team System SKUs
    • Architect
    • Developer
    • Tester
  • Additional cost: Upgrade cost of $1200 retail per seat through June 30, 2006
    • NOTE: Not everyone needs full suite
  • Additional yearly cost for licensing +$1200 retail/year over other Team SKUs

Other products

  • Team Foundation Server – $2799 per proc
  • Team Load Agent – $5089 per proc (1,000 virtual users)
    • Note that Team Tester can control any number of agents
    • Note that Team Tester comes with virtual users (I believe 500?)

Question 2: What do I have to buy?

This depends on your organization. From the literature I have read, you can have up to 5 users on a workgroup edition of Team Foundation Server that is going to be available for those who have bought Team System products, meaning those who have purchased Team System Architect, Team System Developer, Team System Tester or Team System Suite. If you need more than 5 users, you will have to purchase Team Foundation Server.

Team Foundation Server: $2799 per processor, retail. It is possible, for small teams, to have this on a single box. Understand that this is not a good choice for large teams. Let’s look at the specifics to understand.

Team Foundation Server sets up projects with the following items

  1. Source Repository – SQL Server 2005 backend that stores all source code items, as well as any diagrams, SQL scripts that are part of your project. The license to SQL 2005 Standard is included*.
  2. Team Site – Set up in SharePoint Services, the team site is used as the portal for development
  3. Build Server – a server (or service) on top of MSBuild
  4. Reports – SQL Server 2005 Reporting Services serve up code quality and project reports from the portal
  5. Reporting Warehouse – To Trend software quality, etc., some of the reports run against OLAP sources. THis means SQL Server 2005 BI (Analysis Services for the future) have to be installed.
  6. Microsoft Office bits – to Sync project docs (excel lists, project files, etc.)

* Kudos to Patrick Altman for pointing out my shortsidedness. Please note that this particular SQL Server box will be hit rather heavily, so do not feel that it is a good environment for other development. Note also that the license requires anyone using the SQL box have a TFS CAL, which means you would also break your licensing agreement for TFS by adding other applications on SQL Server 2005 that ships with TFS.

This means you have the following products installed on your server(s), each of which is included with the install.

  • Team Foundation Server
  • SQL Server 2005 (Standard included)
    • Database Engine
    • Reporting Services
    • Analysis Services
    • Integration Services – to migrate data to OLAP cubes (from DB engine to Analysis Services)
  • MS Build with build service
  • SharePoint Portal Services
  • Hook into Microsoft Office, primarily Project

As you can imagine, a busy team can overload a single proc box, no matter how good the CPU is. In addition, the warehouse update operations (configurable) can use up a lot of resources. For larger teams, you should consider separating the SQL bits from the other parts, which means additional CPU licenses for each proc on each box. If in doubt, start with one and test your load.

Load Test Agent

If you need higher levels of stress, you have to buy load test agents ($5089/proc). While the cost may seem daunting, it gives you 1,000 virtual users per license, which is inexpensive compared to competitive products. You could, theoretically, set up a bunch of Team Test agents, but each one would have its own analysis and not reflect load as a whole, potentially skewing results to where they are unusable.

Bottom Line

You will need to use your free upgrade (you do have MSDN Universal, right?) to Team System SKUs. In general, you should have at least one Architect, one Test and the rest Developer. For very small teams, one Team Suite ($1200) and the rest Developer is a good option.

  • Architects – Team Architect or Team Suite. Decision point is whether or not your architect also codes and needs Unit Testing tools; if so, Team Suite.
  • Developers – Team Developer
  • Testers – Team Tester
  • Multiple Roles – Team Suite

Like anything else, you have to figure the mix. Renewal cost: $300/year more than Professional only with Premium Subscription (this is $1500 more than Visual Studio 2005 Professional  with Pro subscription, so those not needing Team System can go the SourceSafe route ($549 retail) and save money; I do not advise this direction for Enterprise shops).

Team Foundation Server – $2799 per proc

You will need TFS if you are larger than five users and it might even be wise in smaller shops.

Load Agents

Your call. If you are mostly making sites that service a small number of users, load agents are a luxury. In addition, if you have a test suite already, like Mercury, you might be wise to at least wait for maintenance cycle to end before biting this bullet. The benefit of the Microsoft licensing over some other test tools is the per proc without maintenance fees versus the cost of maintenance with other Enterprise test suites. Be wise and compare features to ensure you are not losing anything, as this is effectively a 2.0 product for Microsoft, while other Enterprise suites are much more mature.

Visual Studio Install Annoyances

For anyone who has not tried to install Visual Studio Team System and the Team Foundation on a single VPC, you have not had much fun. In the release version of Team Suite (only have the download version currently), the install pukes when attempting to install the clr debug bits (which consists of a single text file that states it is simply a placeholder). WTF?
Don’t get me wrong. I am fully in support of the idea that installers should fail when critical pieces cannot load. I am also in agreement that they should clean up. But, should failure on a placeholder file be reason enough to stop the rest of the install? I would disagree with this logic.