Tag Archives: Visual Studio

Keeping Up with TFS 2010 Service Packs and Updates

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!

Visual Studio Tip: Using the Task List Pane

I was in a meeting the other day and a question came up about the purpose of the Visual Studio Task List. A couple of the developers had never used it before, so I thought it’d be a good topic for the blog.

Task List tab in Visual Studio

The Task List, by default, appears in the bottom left window pane of Visual Studio (the same place where build errors and warnings appear). Alternatively, you can find it under the View menu. Microsoft provides some basic documentation on the Task List feature here. However, the documentation glosses over some developer best practices, so I thought I’d expand on that a little.

NOTE: Before I go further, I want to preface everything by saying that the task list should not replace more robust issue tracking systems, like TFS Work Item Tracking, Microsoft Project or another 3rd party product backlog or issue tracking solution. That being said, the Task List can be beneficial in defining more granular programming tasks that may not be appropriate in a higher-level work tracking system.

Code Comments vs. User Tasks

Two types of tasks can be captured in the Task List pane: User Tasks and Code Comments.

User Tasks provide generic notes that a developer may want to remember during development. They work pretty much like Outlook Tasks do, except without any of the features that make Outlook Tasks useful. After about five minutes, you’ll quickly realize just how limited User Tasks are. I usually stay away from them because

  • Most of what I have used them for, I should be putting in an Issue Tracking / Work Item Tracking system.
  • User Tasks are not stored in version control; therefore, other developers cannot see them and I lose them if I ever move or delete my local working environment.

Let me spend a moment longer on that last bullet, because I think that’s an important point.

User Tasks are stored in the developer’s *.suo file, which is not stored in source control by default (nor should it be). The *.suo file contains user-specific preferences, such as the state of the Solution Explorer, which should not be shared across developers. When another developer opens a solution for the first time, a new *.suo file will be created automatically.

This leads us to Code Comments, which are much more useful. Code comments are literally comments in your code (hence the name) that have been prefaced with a pre-defined keyword. Creating code comments is a very straight-forward activity:

'VB.NET
Try
    'some code here
Catch ex as Exception
    'TODO: Need to implement roll-back feature in transaction.
    Throw
End Try

 

// C#
Try {
    // some code here
}
Catch ex as Exception {
    //TODO: Need to implement roll-back feature in transaction.
    throw ex;
}

By preceding a comment with “TODO”, it automatically appears in the Task List. As you can see below, it is possible to see all code comments within your project/solution at once:

Image of task list pane

Task List pane with all-important programming tasks

Code Comments improve upon User Tasks in a variety of ways. For example, code comments allow you to “bookmark” your code in case you need to come back to it later for refactoring or a re-design. Also, code comments are in source code. Source code is stored in version control and shared among the development team. See where I’m going with this?

I hope this helped shed some light on another little feature of the Visual Studio IDE.

MSDN Article: Using XML Comments

The May 2009 MSDN Magazine has a good article reviewing XML comments and their usefulness for code development and documentation.  The article is primarily written for VB developers, but the concepts do apply to C# developers as well.

I’ve been using XML comments since Visual Studio 2005 came out.  For your VB developers still developing legacy .NET 1.1 / VS 2003 apps, you can install the VBCommenter add-in, which will give you some of the basic functionality (C# developers have this out-of-the-box).

If you’re not familiar with XML comments – or if you’ve heard of them, but haven’t tried them out yet – give the article a look.

A Coder’s Challenge

I was recently “challenged” by a fellow agile member who claimed that Java developers have a higher maturity level then their fellow .NET developers.  His claim was that .NET developers rely too much on the mouse when programming, which makes them slower because their hands have to leave the keyboard more frequently.  Java developers, on the other hand, are more familiar with their tool (e.g. IDE) and all the keyboard shortcuts that are programmed into it.

So, I considered his claims and his challenge.  I scoured the interwebs, searching for the knowledge I sought that would help me master the .NET coder’s tool of choice (the great Visual Studio), until I found what I was looking for.

And so, for my fellow .NET “adolescents”, I share with you this, straight from our god herself:

You threw down the gauntlet, B.C. and I accept your challenge.

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);
    dlg.ShowDialog(this);
}

// 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!");
    }
    dlg.ShowDialog(this);
}

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.