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.