[MSSCCI] Confusion about extra subfolder when adding a remote VS project to the local solution

Question

Hi*

We're implementing a MSSCCI provider. Among other IDEs it should support VS2005/2008.
We observed a strange behavior of VS which seems to appear only with your provider (VSS6.0&VSS2005 behave different). So, following scenario: I work with VS2005. The open solution has a single project which was added to the SCC system before. Now, I invoke "Add Project From Source Control", select a folder in the SCC which contains the project files (csproj) e.g. /projects/solution/project1 and select a local folder c:\dev\prj1 . We pass those information back to VS with the return of SccGetProjPath. Then we got the following calls from VS:
SccOpenProject(with local path: c:\dev\prj1)
SccPopulateList(we invoke the callback for the project files in /projects/solution/project1)
SccGet(for the csproj.vspscc file)
SccQueryInfo (for csproj.vspscc file, returned status is "CONTROLLED")
SccCloseProject
SccOpenProject(local path is now c:\dev\prj1\project1)   <= Why does VS change the local path?
... followed by some calls of SccGet and SccQueryInfo to get the files to c:\dev\prj1\project1
SccCloseProject
SccOpenProject(with local path: c:\dev\prj1)

So after the operation the files are under c:\dev\prj1\project1. We are very confused about the VS side change of the local path and the related extra Open/Close project. In VSS6.0/2005 the file are checked out directly to the selected local folder. Is there some option/capability to set/provide to avoid this behavior?

Florian

p.s.: The capabilities we're currently support:
SCC_CAP_RUNSCC, SCC_CAP_GETPROJPATH, SCC_CAP_MULTICHECKOUT, SCC_CAP_COMMENTADD, SCC_CAP_REMOVE, SCC_CAP_TEXTOUT, SCC_CAP_COMMENTCHECKIN, SCC_CAP_HISTORY, SCC_CAP_RENAME, SCC_CAP_DIFF, SCC_CAP_BATCH, SCC_CAP_COMMENTREMOVE, SCC_CAP_COMMENTPROJECT, SCC_CAP_REENTRANT, SCC_CAP_POPULATELIST

Answer 1

We did a bit more investigation regarding this theme: It seems this behavior is related to the mssccprj.scc files - so if we uses  them, indicated by "SOURCE_CONTROL_SETTINGS_PROVIDER" = "PROVIDER" in the csproj.vspscc file, there will be no extra open/close of on scc project and no change into the subdirectory -so the file will be downloaded into the choose local path.
Even if the proper support of mssccprj.scc file might solve this specific problem, I wounder if there are other cases where VS changes the local path independently and unforeseeable into a sub directory? Since this behavior causes serious problems for our scc provider we're very interested to know a bit more about that :)

Florian