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!".


2 Responses to Using SourceSafe & Visual Studio .NET in a Team Environment

  1. Patrick Altman says:

    Why not just use Subversion and avoid SourceNotSoSafe?

  2. Gregory says:

    Personally, I prefer the new Team Foundation stuff, but both CVS and Subversion are greate open source SCCs. SourceSafe is really not as bad as it is touted as being, but it does requiring a bit of an understanding, which was the point of the blog entry. 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: