Category Archives: Visual Studio

VS 2008 and TFS 2013: It Works… if You Can Risk It

VS 2012 LogoNevermind my 20-month hiatus. Life happened. Now I’m back. On with the post.

With the release of TFS 2013 (huzzah!) came another round of regression testing where I work. Of note this time around was the deprecated support of Visual Studio 2008.

Per Microsoft’s own documentation:

To connect to Visual Studio Team Foundation Server 2013 from Visual Studio 2008 or Team Explorer for Visual Studio 2005 Team System requires installation of Microsoft Source Code Control Interface (MSSCCI) Provider 2013. This configuration supports users in accessing Team Foundation version control from these earlier client versions.

In general, I’m happy to see Microsoft deprecating support of three-generation-behind products – I was elated when they dropped VS 2005 support in TFS 2012 – but this time the reaction was mixed. Here’s why.

Yes, Visual Studio 2008 is a three-generation-behind product and, with Visual Studio’s multi-targeting support, upgrading the IDE has become increasingly trivial. My concern is not with Visual Studio. Instead, it’s with BIDS.

BIDS 2008 is VS 2008

Yes, BIDS. As in Business Intelligence Development Studio, the VS 2008 Shell that ships with SQL 2008 and SQL 2008 R2.  SQL 2008 R2 is technically only one generation behind the latest release, yet it relies on the VS 2008 shell for Business Intelligence development (such as SQL Reporting Services, SSIS and SSAS projects).  With the release of SQL 2012, the product team packaged a new version of BIDS, dubbed SQL Server Data Tools 2012 (which runs on the VS 2010 shell – confused yet?).

Here’s the rub.  While you can develop SSRS reports in SSDT 2012 and deploy them to SQL 2008 (or R2) environments, you cannot do the same with SSIS and SSAS packages. For whatever reason, the SQL team coupled their design tool versions with the SQL server run-time environment. So SSIS 2008 packages must be deployed to SQL 2008 environments; SSIS 2012 packages to SQL 2012, etc. Again, per the MSDN documentation:

Use the SQL Server 2008 version of Business Intelligence Development Studio to develop and maintain packages that are based on SQL Server 2008 Integration Services (SSIS).

Now, my company has made a pretty good investment in business intelligence solutions, including SSIS and SSAS. So for developers who are still running SQL 2008 R2 environments, what does this mean to their productivity if we migrate to TFS 2013? Must they undergo the slow torture that is MSSCCI?

Is it Really Broken?

So back to the title of this blog… In regression testing TFS 2013, I wanted to see what all would happen if I tried to connect a TE 2008 client to our TFS 2013 RTM instance. Would Microsoft have a friendly error message waiting for me? Would things try to work only to crash and burn horribly? My, what surprises were in store for me.

For my testing environment, I was running VS 2008 w/ SP1 with BIDS 2008 R2 installed as well as the TFS 2012 GDR. And everything. Worked. Normally. Or as normally as it had run under TFS 2012.

  • Version control worked as expected (check-in, check-out, branching, labeling, shelving, etc.)
  • Work Item tracking opened as usual. I could create and edit work items. And I could view any flat-view queries as well.
  • TFS builds kicked off as well, though I didn’t try to create any builds from the 2008 client.

So it looks like Microsoft’s statement that VS 2008 requires MSSCCI is not entirely true.  Not that I’m complaining. As much as I’d like VS 2008 to undergo the MSSCCI treatment, I can’t say the same for BIDS. Of course, while it technically works, don’t expect Microsoft to support it.  That’s the risky part that you’ll have to figure out whether to take on. Best case, everything continues to work as expected. Worst case, something breaks and you have to install the 2013 MSSCCI. Or get off VS 2008 / SQL 2008. Though one would be considerably easier than the other.

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!

Changing Roles

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!

Certified Again

Last year, I mentioned passing my first Microsoft certification exam to get certified in the .NET 3.5 Framework (exam 70-536). Earlier this month, I took one step closer to getting my web development MCPD by passing – nay, acing – exam 70-562.  And with this exam completed, I can now create a fancy little logo for my accomplishment.  (It’s the little things…):

MCTS ASP.NET 3.5 Framework Certified

With any luck, I’ll have the third exam under my belt in the next month and be done with it… until it’s time to upgrade.

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:

    'some code here
Catch ex as Exception
    'TODO: Need to implement roll-back feature in transaction.
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.