Tag Archives: c#

TFS API: Check if Server Path Exists

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!");

Anonymous Methods in C# 2.0

I love the anonymous methods feature that was added to C# 2.0. I got a taste of this feature in college when I used Java (which refers to them as anonymous inner classes). Regardless, this is yet another feature to help developers write cleaner code.

For example, let’s say your application has a button that, upon clicking, shows an “About” dialog, which displays various information about your application (e.g. version, logo, etc.). Upon closing that dialog, you’d like to display a message box, telling your user that they just saw your “About” dialog box (because users like having to click a lot…).

In C# 1.x, you’d have to write the following code to accomplish this:

private void Button1_Click(object sender, EventArgs e)
    AboutDialog dlg = new AboutDialog();
    dlg.Closed += new EventHandler(OnAboutDlgClosed);

// separate method for handling the form close event.
private void OnAboutDlgClosed(object sender, EventArgs e)
    MessageBox.Show("You just saw my About dialog!");

However, in C# 2.0, you can do the same thing using anonymous methods:

private void Button1_Click(object sender, EventArgs e)
    AboutDialog dlg = new AboutDialog();
    // .NET 2.0 changed the name of the event to FormClosed
    dlg.FormClosed += delegate
        MessageBox.Show("You just saw my About dialog!");

That’s it. Frickin’ sweet!

Ok, so there are a couple drawbacks that I’ve found while using anonymous methods. First, I’ve found that I cannot use the “Edit and Continue” feature in the Visual Studio 2005 Debugger. That is, I am not allowed to make a change in the method or anonymous method while stepping through the code — instead, I have to make my code change and restart the debugger. A minor nuisance, but still a nuisance.

The other potential issue is that, assuming the code in the anonymous method needs to be executed in response to multiple events, some developers may find themselves copying and pasting the code in several places of their application, thus ignoring the general rule of code re-use.

This second issue can be very subtle. It is a problem of design, and it is up to the developer to be on the lookout for it. In cases like this, the C# 1.x example would be a good solution that promotes code re-use.

Refactoring Idea

As I was refactoring some of my code at work today, I found another example of refactoring that would come in handy: De-sugaring code segments that are syntactically sugared.

In my case, I had to support a changed business rule that required nullable DateTime objects instead of ValueType DateTime objects. So I tried to change

DateTime dtNull = ( /* my condition */ ) ? new DateTime() : DateTime.Today;


DateTime? dtNull = ( /* my condition */ ) ? null : DateTime.Today;

Of course, Visual Studio gives me a compiler error if I make this change because “there is no implicit converstion between <null> and ‘System.DateTime'”. However, the following does work:

DateTime? dtNull;
if ( /* my condition */ ) {
    dtNull = null; }
else {
    dtNull = DateTime.Today; }

It seems that refactoring something like this should be very easy to automate. Unfortunately, to my knowledge, Visual Studio 2005 is not as extensible in the area of refactoring as it is in the area of Code Snippets.