Category Archives: Team Foundation Server

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

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

Book Recommendation: Professional Team Foundation Server 2010

2 Replies

The latest addition to my technical book collection is Professional Team Foundation Server 2010 . This is a “must have” book for anybody who is a TFS admin or even a Team Project admin.

I’m about two-thirds of the way through the book and I honestly can’t go more than one or two pages without finding some new tip or piece of information to try out in my own environment. The great strength of the book comes from the wealth of experience the authors drawn upon when discussing each of the topics.

The book itself takes a comprehensive look at the many aspects of Team Foundation Server, including version control, work item tracking, reporting, process templates, build, and administration. The administration content is extremely useful and the topic is given a full third of the book. For anybody who works in an enterprise environment or who has to deal with high availability and disaster recovery systems, you’ll be glad to see chapters devoted specifically to addressing these topics.

Lastly, for anybody interesting in pursuing the Microsoft certification for Team Foundation Server 2010 (exam 70-512), this has been touted as the unofficial training book.

TFS’ Lack of Support for Linked Reports – Bah!

Leave a reply

I posted this issue on the MSDN forums, but wanted to cross-post it on my blog as well.

One of my recent challenges at work has been around building custom reports against TFS, specifically around version control. TFS provides a lot of nice reports related to Work Item Tracking and Build Automation, but very little around version control. (For example, how long has something been checked out of TFS?)

While I understand the big-picture reason for this – code changes should be linked to work items to allow for requirements traceability – it is also a common scenario for new development teams to start out using TFS solely for version control.

In tackling these custom reports, I was looking for a way to deploy a single report and have it be available in each Team Project as a linked report (a capability available in SQL Reporting Services). This provides improved maintainability in that I can deploy updates and fixes to a single deployment target rather than deploy copies of reports to each Team Project on my Collection or server.

Based on my research, I concluded the following:

Linked Reports do work when being viewed on the Reporting Server directly.

On the Report Server, I created a new folder under /TfsReports/DefaultCollection, called “SharedCollectionReports“. This is where I would store all of my reports that are shared across team projects in a collection. I then used Visual Studio / BIDS to deploy my RS report to this new location.

From here, I created a linked report to two different Team Projects and set up unique report parameters for each (but still using the same base report). I confirmed that each report returned data unique to its parameters.

Linked TFS Report in SQL Reporting Services

I then made a change to the report and re-uploaded a newer version of the base report to the “SharedCollectionReports” folder and confirmed that the linked reports in both team projects reflected the changes.

So, this functionality does work as expected when accessed directly from the Report Server.

However…

Linked Reports are NOT visible in Team Explorer

Unfortunately, when opening up the Team Project in Visual Studio Team Explorer, the linked report does not show up.

Team Explorer not displaying linked reports

Linked report missing from Team Explorer view.

Unfortunately, it looks like this has been a known issue for a while, based on a related MSDN thread I found.

I’ve posted a feature request on the Visual Studio/TFS User Voice site. If this is a feature you would also like to see added to TFS, please vote for this feature.

Keeping Up with TFS 2010 Service Packs and Updates

Changing Roles

TFS API: How to Get a Specific Version Programmatically

1 Reply

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.

Agile .NET Geek

A blog about Agile Development, .NET technologies, and other miscellaneous stuff.