Author Archives: Matt

TFS API: How to Get a Specific Version Programmatically

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.

TFS: Get Specific Version Options

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:

  • ChangesetVersionSpec
  • DateVersionSpec
  • LabelVersionSpec
  • LatestVersionSpec (equivalent to VersionSpec.Latest)
  • WorkspaceVersionSpec

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.

Visual Studio 2010 News from Microsoft

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…

  • The official release date for Visual Studio 2010 is March 22, 2010.  This and some other announcements can be heard on the latest Radio TFS podcasts.
  • Visual Studio 2010 Beta 2 was released on Monday (Oct. 19th) to MSDN Subscribers.  The aforementioned podcast also hinted that a Virtual PC image with VS 2010 Beta 2 made be released shortly.  If not, Brian Keller has posted another video on how to download and install the Beta 2 software.  Between this and information from my previous post, you should be able to set up a Virtual PC image with the correct bits.
  • Expect to see a lot of new webcasts on Visual Studio 2010 at Channel 9 in the coming days/weeks.
  • Microsoft also announced that they are revamping their licensing structure to correspond with the new version.  Brian Harry discusses this in more detail on his blog.

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.

Microsoft Windows and ASP.NET Tutorial Sites

I’ve been a fan of the Microsoft’s ASP.NET site for a while now.  If you’re not familiar with it, the site contains an awesome amount of information and resources for ASP.NET developers.  One of my favorite features of this site is the Learning section, which contains a large number of tutorial videos covering a range of different technologies, tools and controls within the realm of ASP.NET development.  While the videos are not usually in-depth on any single topic, they do provide great introductory examples to help me get past a lot of my initial hurdles and start developing something to cater to my specific needs.

Today, I came across theWindows Forms and WPF equivalent of the ASP.NET site, and I was amazed that I hadn’t thought to look sooner.  This site has the same great information and resources I was used to seeing for ASP.NET.  And this site also has a large number of video tutorials, both catering to the traditional Windows Forms developers as well as those moving into the WPF space.

This site has already made its way onto my list of useful work resources.  Today’s video was a review on how to use the BackgroundWorker class to simplify multi-threading.

Check In Code Frequently for Roll-back’s Sake

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).

key-undo

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:

  • The implementation was not going to work
  • The implementation would have created more maintenance overhead than I wanted
  • The scope of the implementation became much better than what I wanted to bite off

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:

  • The first time you intentionally rollback (read: DELETE) your code changes, it’s kind of scary!
  • The second time, it’s a little scary, a little exciting, maybe even a little deviant-like.
  • Subsequent times, it’s empowering. And you wonder why you weren’t doing it sooner.

Control key 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.