Grant Holliday posted a really nice reference guide yesterday explaining the various Service Packs and Hotfixes that are currently available for TFS 2010 and its underlying components. This is something I had been searching for recently to ensure my own TFS installation was up-to-date. It is very thorough and highlights several aspects of the TFS infrastructure.
Thanks for putting this together Grant!
This week, I made the transition to a new team within my company. It’s good to make a change every once in a while so that things don’t get stale. I’ve heard it said that, as soon as you are so comfortable in your current role that you’re afraid to make a change – that’s when it’s time to try something new. 🙂
My new role is a bit more technical than my last and will give me more time to dig deeper into the latest .NET technologies out there. I’m also going to be doing a bit more TFS administration. I’m looking forward to seeing how TFS works “under the hood” and be able to play around with all the cool new ALM features that are getting baked into the product.
I know I’ve been pretty lackadaisical lately with my posts. To tell you the truth, I just wasn’t getting a lot of time to play with the tools, technologies and practices that this blog is all about, and I just didn’t have anything noteworthy to write about. With this new role change, I expect that will change.
Most of you have visited this blog for TFS-related content. Look for more of that (and other topics) to come!
Within the Visual Studio Source Control Explorer, there are a number of options available for getting files out of TFS. Often times, developers just want to get the latest code to work with. But in some scenarios, developers need to get source files based on alternate criteria, such as by a specific date or label. TFS provides a handful of options for selecting source files easily within the “Get Specific Version” dialog.
This works really well within Visual Studio, but how can you do this programmatically? As it turns out, the Workspace.Get() method has an overloaded method that takes a VersionSpec argument. Notice that VersionSpec is actually a base class. and that there are several inherited classes that can be used to specify the changeset type, including:
For example, if you wanted to perform a GET on a specific changeset, you would simply pass an instance of ChangesetVersionSpec:
'connect to source control and get reference to existing workspace
Dim server As TfsTeamProjectCollection = _
TfsTeamProjectCollectionFactory.GetTeamProjectCollection("http://myTfsServer:8080")
Dim vcs As VersionControlServer = _
server.GetService(Of VersionControlServer)()
Dim ws As Workspace = vcs.GetWorkspace("MyExistingWorkspace", My.User.Name)
'Perform a GET on Changeset 100
Dim version As New ChangesetVersionSpec(100)
ws.Get(version, GetOptions.GetAll)
Performing a GET based on a pre-defined label works in much the same way (just replace the ChangesetVersionSpec object with a LabelVersionSpec object):
'connect to source control and get reference to existing workspace
' (same as above)...
'Perform a GET on items defined by label "My Label"
Dim version As New LabelVersionSpec("My Label")
ws.Get(version, GetOptions.GetAll)
Updated 2/28/2012: Revised code sample for TFS 2010 API.
For those of you keeping tabs, Microsoft recently released a slue of information regarding the next versions of Visual Studio and Team Foundation Server.
Some of the highlights…
Lots of exciting news out of Microsoft. I was kind of hoping that they’d release this yet in 2009, but I’m glad they’re taking the extra time to work out the bugs rather than rush the product to production too early.
One of the best practices around source-control is the idea of checking in code frequently. “Frequently” is, of course, a relative term. Some take this to mean checking in code within a matter of hours; others, days. Some suggest check-ins should occur every time a new feature is added. Then the question becomes: What constitutes a feature? Is a method of a class a “feature”? Is a class a “feature”? Is a feature based on a user story? A Use Case? A bulleted item in a requirements document?
For me, I’m prescribe to the practice of checking in per feature. And, by feature, I mean a Use Case (or a single flow of a Use Case), or a backlog requirement. Of course, some features take more time to implement than others. But this is ok. Sometimes, I’ll check in within a couple hours. Other times, I might check in after a couple days. Rarely, however, do I leave files checked out for more than 2-3 days (if that gives you an idea how “large” I spec these features).
One of the many benefits of checking in frequently is that you allow the ability to rollback in-progress code changes that are not panning out. For some of you, this may be a completely foreign idea. “Delete my code?! Are you loco?? This code was spawned from the magnificence that is my brain. It is precious.”
If that was your reaction,… well, if that was really your reaction, then you should probably stop reading. Wait, don’t stop reading. I need the subscribers… For those of you that had a bit more subtle reaction, consider this anecdote:
This morning, I was coding up a new feature for an active development project. All previous code had been checked in before starting this new feature, so I was starting from a stable build. Starting out, I was trying to figure out the best way to implement this new feature. In some cases, some up-front design and modeling would have been useful – but, in this case, where I was working with a few unfamiliar .NET classes, it made more sense to just try out a few different approaches programmatically and get a feel for which worked best.
In the span of about 90 minutes, I had implemented – and subsequently rolled back – five code changes before finding an approach that finally worked.
Some of the reasons for rolling back the first several changes included:
Also while making these development changes, I noticed Visual Studio modifying a number of auto-generated files that I don’t normally touch (including project, .settings and .resx files). It would have been very difficult, if not impossible, to go through these files manually and find all the changes that were made. But because I was rolling back all of the files via TFS, there was significantly less risk of introducing unstable code (or accidentally leaving leftover code) in a later build. It was also considerably faster than manually traversing the code for delinquent code.
If you’re not accustomed to rolling back code in your development cycle, it’s feels kind of like this:
So if you are (or know someone who is) in the camp where code check-ins are almost an afterthought, consider this example and think about the value that frequent check-ins can add to the development cycle.
Disclaimer: Rarely do I get a chance to totally geek out and write a post specifically about code. I enjoy the change-up. And hopefully some of you will benefit from this.
Ok. On a recent project, I’ve been playing around with the .NET APIs that were made available for interacting with TFS. You can tell that the documentation for these API’s are a little more raw than what is available for the .NET framework components, but that is not to say they aren’t still helpful.
As part of my project, I needed to programmatically download files to the local machine from version control. As part of my unit testing, I wanted to validate the source path before attempting the download. Basically, I wanted the equivalent of the System.IO.Directory.Exists() method in the .NET framework, but that validates against version control.
After several minutes of searching, I found the VersionControlServer.ServerItemExists() method. This handy method basically combines the functionality of the File.Exists() and Directory.Exists() methods, switching between the two (or combining) by setting the custom ItemType enumeration.
Using this method, I can first validate the path, as the following example shows:
Dim fakePath As String = "$/MyFakeTeamProject/RoadToNowhere"
Dim vcServer As VersionControlServer = Nothing
'...initialize a reference to the version control server here...
'Perform validation against server path before downloading.
' This example works for both file or directory paths.
If Not vcServer.ServerItemExists(fakePath, ItemType.Any) Then
Throw New Exception("Hey! The path you gave me is bunk!")
End If
…and for the C# folks:
string fakePath = "$/MyFakeTeamProject/RoadToNowhere";
VersionControlServer vcServer = null;
//...initialize a reference to the version control server here...
// Perform validation against server path before downloading.
// This example works for both file or directory paths.
if (!vcServer.ServerItemExists(fakePath, ItemType.Any))
{
throw new Exception("Hey! The path you gave me is bunk!");
}