Yesterday, I took (and passed) the Microsoft Certification exam 70-536 (Technology Specialist: .NET Framework – Application Development Foundation). Three months worth of studying and it finally paid off.
Just wanted to share. = )
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.
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.
InformIT recently posted an interview with Scrum evangelist Mike Cohn. The interview has a lot of great information and hits on a number of points, including the benefits of user stories and agile estimating, and some of the reasons why many companies fail to successfully transition to Agile.
Check out the interview here.
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.