TFS Licensing

When you buy an MSDN Premium (or formerly Universal) subscription, you get development licenses for a wide range of MS servers. These server licenses are only good for development and testing purposes, not for production use. The idea is that if you are developing a solution using these servers, you don't need to run out and purchase a full blown license for the server. This is a great idea to help keep costs down and promote MS Server based solutions.

The exception to the above is the Team Foundation Server. With the Premium subscription, you get a license to use a limited 5 user version of the server (Note: the limitation is on the number of users, not the functionality of the server) for what I would argue is production use. In other words, you can use the Version Control, Work Items and other features as if you bought the full server (as long as you stay within the 5 user limit). This is significantly different than the licensing for all of the other servers included with the Premium subscription.

So, what do you do if you want a server to develop and test the customisations that you are doing to your full-blown production TFS server? Well, if you have more than 5 developers or you want to test a solution with more than 5 users (including performing load testing), you need to buy a copy of the retail TFS server! That's right, no special development server license is available, you need to either use the 5 user edition or buy a full server license. Granted, the server isn't that expensive and you should already have the client licenses (Team Foundation Explorer), but it really would be nice to have a development licensed server.

Microsoft, are you listening?

Source Control: Where in TFS did my solution go?

I just spend 15 minutes frustrated at my computer because VSTS kept automatically checking my source into the wrong project. All the information on the Net said, “right click on the solution, click Add to Source Control, select the project you want to add it to, and voila, instant version control!” That’s just great, except that I wasn’t being given the option to check my code into a specific project; the source just flew somewhere out of my control. So I figured, hunt down the source files, delete them, try again. When I found out which project my source was being saved in and deleted the files, I found myself present with no source control options for my solution at all. After unbinding the files (see last paragraph), I was able to try to check them into source control again. Same problem occured once more.

It turns out that at some point in time my base directory (lets call it D:/) had managed to become mapped to this other VSTS project. Thus, any and all projects that resided somewhere on my D: drive which needed to be added to source control, would automatically go there. So if you’re trying to add to source control and files are being saved not in the project you expect, check for that condition first.

Under Source Control Explorer, select Workspaces… from the Workspace pulldown menu, then Edit -> Working Folders, select the one that lists the base directory under Local Folder, and hit Remove.

Another useful thing I stumbled across in my quest for the holy grail of source control… the Change Source Control button, home of the Unbind option. To reveal it, go to View -> Toolbars and select the Source Control – Team Foundation option. On the new toolbar that appears, the Change Source Control button is the yellow-gold one that vaguely looks like two cylinders on the left. When you open it up, it lists your active solution and projects, and presents you with the option to Unbind your source if it is currently resident in source control. You still have to manually delete the files that were previously checked into the wrong project though.

-me.

Welcome to MarshalByRefObject

Ah, the welcome post. It's a strategically critical post where we outline who we are and why we are doing this.

As to the why, it's pretty simple really. We hope to share some of the things we've learned, and will learn, with the community at large to give back for all the times we have been helped by others. Either that or, as one of our contributors likes to say, become world famous through our blog so that we can demand incredibly high salaries.

Now that we have that cleared up, who are we?

We're a group of software developers that are working with Visual Studio 2005 Team System Developer edition. We have a mix of Win32 C++, managed C++ and C# code (there's the odd bit of VB, but we don't like to talk about that :). One of our current (and, I'm sure, ongoing) projects is customisation of our internal Team Foundation Server (for which the hardware is almost here). We will be creating migration apps (for PVCS and TRACK data), applets that are triggered by TFS events, custom build scripts, Work Items, etc. Essentially, we will be touching pretty much every area of the TFS server in order to better fit our internal processes. We hope to share some of our triumphs (and failures too) with you.

Our "real" jobs are working in product development for a training solutions company. Our products are custom built for our clients with lifecycles that are often one or two years long. Sometimes they are a mix of hardware and software, sometimes just software. Most of our products are "variations on a theme" so we do have the concept of a "product line" (even though every version is custom).

Why the title "MarshalByRefObject"?

1. Because we took a vote and that was the winning entry?
2. Because Marshall is a contributor?
3. Because .NET Remoting is seriously cool?

The answer, my friends, is all of the above (although we won't admit to #2 as we don't want anyone's head to swell :).