ProjectNode does not allow SVsSccManager, SVsQueryEditQuerySave to be overrided to use custom SCC provider


The current interface and implementation of ProjectNode.cs does not allow end user to change the SCC provider other than the default SVsSccManager or SVsQueryEditQuerySave.
sited methods are :
internal bool QueryEditProjectFile(bool suppressUI)
protected void RegisterSccProject()
protected void UnRegisterProject()
in all 3 functions, when the end user needs to implement custom SCC provider packages (in VS Isolated or integrated shell), the methods are closed off from extending and method always returns the default SCC provider and not the end-user custom SCC provider, causing SCC operations to be incorrectly executed.
I am proposing to fix this (add extensibility) by changing the interface to the following:
protected internal virtual bool QueryEditProjectFile(bool suppressUI)
protected virtual void RegisterSccProject()
protected virtual void UnRegisterProject()
Similar approaches were taken on other functions, as well as in the HierarchyNode.cs class.

file attachments


alinconstantin wrote Oct 10, 2008 at 9:38 PM

ProgrammerJoe - you have a misunderstanding on how scci works in VS.
ProjectNode.cs implementation is correct. It calls the SVsSccManager service. There is only one such service in VS, and this is implemented by msenv.dll.
If you're implementing a VS package and a source control provider you're implementing a different service, and you're NOT overriding the SVsSccManager. SVsSccManager will delegate calls like RegisterSccProject, GetSccGlyphs, etc to your scc provider IF your provider IS ACTIVE (settable in Tools/Options/SourceControl). SVsSccManager works with SVsRegisterScciProvider service (also implemented by the shell) to figure out what is the active scc provider to which the calls should be delegated.
If there is no source control provider set active to which the scci calls can be forwarded to, services like SVsSccManager, SVsQueryEditQuerySave, etc will try their best to satisfy the calls and return a good response from calls to RegisterSccProject, QueryEditFiles, etc. (E.g. return S_FALSE from RegisteSccProject, allow silently in-memory edits or change the files attributes on disk if the files are read-only, etc)

There is no "default SCC provider" concept in VS.

ProgrammerJoe wrote Oct 25, 2008 at 12:01 AM

I have based the custom SCC design on the SDK sample at

C:\Program Files\Microsoft Visual Studio 2008 SDK\VisualStudioIntegration\Samples\SourceControl\CSharp\Example.SccProvider

I have also followed registration as described in MSDN http://msdn.microsoft.com/en-us/library/bb165948(VS.80).aspx , place our SCC provider GUID in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\ X.Y\SourceControlProviders\ as the default SCC provider, as according to SCC registry description

We have also set the Visual Studio Options dialog box to select our SCC provider by default, and proved in debug mode, we have also observed that our SCC package's SetActive() call is called and executed with success.

We also tried to have the SCC package autoloaded using the ProvideAutoLoad() attribute and tested with success. However the SVsSccManager still cannot route calls to our SCC provider.

We have determined 2 possibilities
  1. there may be a bug in registration process to SVsSccManager.
  2. there are undocumented steps in registration missing from the following page:

We found a clause in the Registration and Selection (Source Control VSPackage)
"A source control VSPackage is called when any solution is opened and the registry key for the VSPackage is in the solution file. ... Source control VSPackages must implement the IVsSolutionPersistence to enable automatic solution-based VSPackage swapping"

The SCCProvider sample does not support registration by swapping package. Do you have any suggestions, written instructions or msdn pages to tell how to properly register so SVsSccManager can route calls?

In any case, I saw most MPF class, like HierarchyNode.cs for example, has virtual methods so customer like us can override if really needed. I feel it is consistent to at least provide this ProjectNode.cs to make the pattern consistent across MPF.

Let you know your feedback, thanks.

DmitryPavlov wrote Dec 3, 2008 at 5:55 AM

HI ProgrammerJoe,

Do you agree that this issue should be closed due to alinconstantin arguments?

wrote Feb 13, 2013 at 10:30 PM