TFS Version Control and VS Integration : Integration

When and how does my solution go "offline"?

benryan — Wed, 12 Dec 2007 21:25:00 GMT

TFS 2008 adds improved support for "offline" scenarios. This blog post identifies the scenarios under which a solution will be placed in "offline" mode.

If the Visual Studio IDE is unable to connect to the TFS server when it is opening the solution, then it will mark the solution as being offline. It will also mark the TFS server as being offline.

A messagebox will be displayed indicating the solution was taken offline and a message to the same effect will appear in the Output window.

-OR-
If the Visual Studio IDE is opening a solution and finds the TFS server to which the solution is bound is marked as offline, then VS will mark the solution as being offline

In this scenario, a message about the solution being opened offline will appear in the Output window, but no messagebox will appear.

NOTES

Offline detection is done ONLY during solution open. Failures to connect to the server during other version control operations within VS do not affect the offline state of the solution or server.
The offline state for the solution is stored in the solution's local .suo file.
When the server is marked offline, we also turn off the server's "AutoReconnect" setting.
The server's offline state is stored in a registry value named Offline, and the AutoReconnect state is stored in in a value named AutoReconnect. Both of these live under the key:
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\TeamFoundation\Servers\<tfs server name>
A solution remains offline until it is explicitly taken online.
A TFS server remains marked offline until an offline solution bound to that server is taken online.
Opening a solution that was previously marked offline while its server is still marked offline opens the solution without any messageboxes appearing. We will present a message in the Output window indicating the solution is still offline.
Opening a solution that was previously marked offline when its server is marked online presents the user with a messagebox asking if the user wishes to take the solution online.

How to make a project compatible with VS source control integration

benryan — Fri, 22 Dec 2006 21:52:00 GMT

The following are the necessary mininum steps required to integrate a new project type with source control within Visual Studio.

The project must implement Microsoft.VisualStudio.Shell.Interop.IVsSccProject2 (documentation).

GetSccFiles - return which files are controllable for the given item ID
GetSccSpecialFiles - return hidden files for the given item ID
SetSccLocation - persist the SCC settings to the project file
SccGlyphChange - notifies project that changes have been made to the indicated items' SCC glyphs

The project must utilize Microsoft.VisualStudio.Shell.Interop.IVsSccManager2 (documentation).

RegisterSccProject - call when the project is opened
UnregisterSccProject - call when the project is closed
GetSccGlyphs - call to get source control glyphs and source control status

The project must utilize Microsoft.VisualStudio.Shell.Interop.IVsQueryEditQuerySave2 (documentation).

QueryEditFiles - call before editing a file in the project to notify listeners (e.g. SCC)
QuerySaveFiles - call before saving a file in the project to notify listeners (e.g. SCC)

The project must utilize Microsoft.VisualStudio.Shell.Interop.IVsTrackProjectDocuments2 (documentation)

OnQuery* - call before attempting the add/rename/move/etc. operation to notify listeners (e.g. SCC) and to give listeners the chance to veto the attempt.
OnAfter* - call after the operation has been performed to permit listeners (e.g. SCC) to perform related operations (e.g. pend an SCC add).

To permit SCC commands to show in the context menus, the menu should contain the following groups:

guidSHLMainMenu::IDG_VS_CTXT_SOLUTION_SCC
guidSHLMainMenu::IDG_VS_CTXT_PROJECT_SCC
guidSHLMainMenu::IDG_VS_CTXT_ITEM_SCC

Introduction

benryan — Thu, 21 Dec 2006 22:19:00 GMT

About Me
My name is Ben Ryan, and I have been involved with developing the Team Foundation Server version control client for the last three and a half years here at the Microsoft office in Durham, NC. During most of that time, I have been working on the low level source control integration of Team Foundation Server within Visual Studio. As time allows, I assist my coworker, Michal Malecki (http://blogs.msdn.com/michalma), with the TFS MSSCCI PlugIn.

I have 14 years of software development experience that span several companies and numerous software projects. My previous employers include:

Ateb - C development on Linux-based signature capture appliance
Alerts.com - Java development of a distributed messaging service
HAHT - Integration of Java VM within native Windows and UNIX HAHTsite server application
Data General (now part of EMC) - C development within DG/UX kernel's TCP/IP protocol stack

This list is not all inclusive, but it does offer a representative sampling of my background.

Blogging Topics
For starters, I intend to blog about Visual Studio source control integration. Ideally, I'll cover both what is involved with making a new project type compatible with integrated source control and how a source control provider interacts with Visual Studio. Hopefully, the latter discussions will provide some insight into how TFS operates within Visual Studio and why it operates that way.

After that, I'm not sure what I'll blog about. I'm not too concerned given that the mysteries of the source control integration layer should provide me with blogging fodder for months to come.