Wednesday, November 27, 2013

Using Visual SourceSafe 2005 with Visual Studio 2010, Visual Studio 2012 and Visual Studio 2013

Visual SourceSafe is out of mainstream support since 2012 and will be in Extended support until 2017. However, may people use the product past its lifetime dates, if for no other reason at least because they have programs developed originally and stored in VSS databases that will still need maintaining.
Microsoft Visual SourceSafe 2005 will still install on modern computers, and will still integrate with recent version of Visual Studio
image

Opening projects from source control

Visual SourceSafe 2005 was changed from VSS 6.0 and integrated with the File/Open Project/Solution dialog in Visual Studio. On Windows XP, Vista (and 7, I think), the Open dialog showed a dedicated ‘Visual SourceSafe’ icon in the tray, so it was intuitive to discover the Open from source control functionality. Since then, Windows changed the layout of the Open dialog, and SourceSafe option can only be found if you scroll the folders tree to the top…
Open Project from SourceSafe in VS 2005image
Even worse, the namespace extension providing integration with Explorer and the Open dialogs broke during the years. Here are the options on how to fix the Open From Source Control functionality:

A) Use SourceSafe 6.0 way of opening from source control.

When it integrated with the File/Open dialog, SourceSafe 2005 has set some registry keys that make VSS Integration package in VS hide the OpenFromSourceControl commands under File/SourceControl menu. You can modify the registry and bring back those commands:
1) Using regedit, open the registry and locate under
[HKLM\SOFTWARE\Microsoft\SourceSafe\Namespace Extension]
DisableOpenFromSourceControl == (DWord)1.

2) Change the value to (Dword)0 or delete the value completely. There will be a similar value for SourceSafe Internet provider under Microsoft\SourceSafe\RemoteAccess\Namespace Extension, change that as well
(Note: The values are under Wow6432Node hive on 64-bit machines)
image
3) Restart Visual Studio and now you should have under File/SourceControl a menu item that allows opening solution from source control.
image
4) Make sure to select a different location when opening from source control in a new enlistment (the equivalent of “Change Destination Folder” in the open functionality from the OpenProject dialog)
 image

B) Fix the namespace extension.

1) If you installed VSS 2005 RTM and try to navigate the namespace extension you will see there are no items available under SourceSafe node. Clicking on the SourceSafe icons in the tree results in an error message “No such interface supported”

imageimage
This error has been fixed in the SourceSafe 2005 Update build, so please install VS80-KB943847-X86-INTL (which you should do anyway)
2) Now you should be able to navigate the SourceSafe databases in the File/Open dialog, you should be able to select a solution or project and change the scc location, however, when you’ll try to open the solution Visual Studio will display another error message “The selected file is not a valid solution file”.
image
Why does this break? Surely you’ve selected a solution file! In order to return the path to the solution to VisualStudio, TDNamespaceExtension.dll which is the NSE deployed by SourceSafe needs to create a URI like msss://SoursafeDatabasePath/~files/PathToTheSolution (there’s more to that, but you get the idea). Unfortunately the MSSS scheme parser is a component implemented by a dll that ships with VisualStudio, so in order to create the parser TDNamespaceExtension looks up in registry under Visual Studio registry hive; as SourceSafe 2005 shipped in the box with Visual Studio 2005 (VS 8.0),  it looks under this registry key
HKLM\Software\Microsoft\VisualStudio\8.0\CLSID\{53544C4D-CFBF-404e-9E37-19C8BB80F6E3}
Of course this key does not exist if you install a more recent version of Visual Studio…
For  Sourcesafe to find the correct parser, the TDNamespaceExtension.dll had to be updated to look under the right key. To make VSS work with VS2008 and VS2010 Microsoft released patches to TDNamespaceExtension (e.g. KB976375 is what you can install for VS2010). But for VS2012 and VS2013 Microsoft hasn’t released anymore such updates, probably due to SourceSafe reaching the end of mainstream support. Sad smile
If you have multiple versions of VisualStudio installed (e.g. I have VS2010, VS2012 and VS2013 installed) and have fixed VSS to work with one version of VS you won’t (I have fixed it for VS2010 installing the KB article mentions above) you see this problem in the other versions, because VSS is able to find the parser from that version of VS (from VS2010 in my case).
Anyway, it’s easy to fix the problem manually even without KB articles, by setting a registry value which tells SourceSafe where to locate the MSSS scheme parser. Besides looking under the VS 8.0 hive, TDNamespaceExtension also looks in a common place, under HKCU\Software\Classes\CLSID\{53544C4D-CFBF-404e-9E37-19C8BB80F6E3}
So we can register the parser there, pointing to the current version of Visual Studio you have installed. E.g.:
- Save the content below to a file with .reg extension
- Edit the 12.0 if necessary and replace with the version of VS you have installed
- Double click the file and import it into registry.
---------------------------------------------------------------------------------
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Classes\CLSID\{53544C4D-CFBF-404e-9E37-19C8BB80F6E3}]
"InprocServer32"="C:\\Program Files\\Microsoft Visual Studio 12.0\\Common7\\IDE\\VS SCC\\VssProvider.dll"
"ThreadingModel"="Both"
@="VAPI Scheme Parser Msss"

---------------------------------------------------------------------------------
Now you should be able to open file from source control using the File/Open/Project without running into the “The selected file is not a valid solution file” error.

Note: The above file worked for me on a 32-bit machine. On my 64-bit machine, I have the VAPI parser registered under multiple locations (I think the last one is written by VS setup and gets copied into 12.0_Config hive on first run); it won't hurt to register it similarly though.

---------------------------------------------------------------------------------
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{53544C4D-CFBF-404e-9E37-19C8BB80F6E3}]
@="VAPI Scheme Parser Msss"

[HKEY_CLASSES_ROOT\Wow6432Node\CLSID\{53544C4D-CFBF-404e-9E37-19C8BB80F6E3}\InprocServer32]
@="C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\Common7\\IDE\\VS SCC\\VssProvider.dll"
"ThreadingModel"="Both"

[HKEY_CURRENT_USER\Software\Classes\Wow6432Node\CLSID\{53544C4D-CFBF-404e-9E37-19C8BB80F6E3}]
@="VAPI Scheme Parser Msss"

[HKEY_CURRENT_USER\Software\Classes\Wow6432Node\CLSID\{53544C4D-CFBF-404e-9E37-19C8BB80F6E3}\InprocServer32]
@="c:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\Common7\\IDE\\VS SCC\\VssProvider.dll"
"ThreadingModel"="Both"

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0_Config\CLSID\{53544C4D-CFBF-404e-9E37-19C8BB80F6E3}]
"InprocServer32"="C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\Common7\\IDE\\VS SCC\\VssProvider.dll"
"ThreadingModel"="Both"
@="VAPI Scheme Parser Msss"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\12.0\CLSID\{53544C4D-CFBF-404e-9E37-19C8BB80F6E3}]
"InprocServer32"="C:\\Program Files (x86)\\Microsoft Visual Studio 12.0\\Common7\\IDE\\VS SCC\\VssProvider.dll"
"ThreadingModel"="Both"
@="VAPI Scheme Parser Msss"
---------------------------------------------------------------------------------

8 comments:

Schooltje said...

Hi Alin,
I have followed your instructions for solving the 'The selected file is not a valid solution file' issue.
But after a restart of my pc I still get the message.
I have created the reg file conform your suggestions only the location of the Visual Studio is updated.
Have you may be another suggestion for me?
Thank you!

Alin Constantin said...

@Schooltje: I'd check the path you set in registry to point to VssProvider.dll (e.g. on x64 machines the folder is "Program Files (x86)", etc.

If you can't get the NSE to work, you can always set DisableOpenFromSourceControl registry value and do the open from source control via the File/SourceControl submenu...

Schooltje said...

@Alin: Thank you for your comment.
I have double checked the path and I think I have set this correctly.
So I have still the issue, I will try the option DisableOpenFromSourceControl.
Is the directory from which the reg file must be executed important?
Thank you!

Schooltje said...

Thank you the DisableOpenFromSourceControl option works.
I have Windows 8.1 installed and this option is located in the 'HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\SourceSafe\Namespace Extension'. Your remark has I read too late.
Can it be that in the regedit file I must do also something special for the 64 bit environment?
Thank you for your help!

Alin Constantin said...

@Schooltje:
The directory for importing the reg file is not important (the reg file was provided so you don't have to input multiple reg values).

But you're right, on x64 system the reg paths are different. I've updated the post with a reg file with all locations where the VAPI parser is registered on my x64 machine.

Schooltje said...

Thank you very much. I have tested this on two machines which have these problems and the update for the 64bits reg file works.

George O'Hare said...

Great article. I could not figure why my new machine would not recognize my sourcesafe .sln file. Thanks

Bryan Johns said...

Excellent article! Saved my bacon today.