Sdílet prostřednictvím


Deploying SourceSafe automation on clean machines

"I've written an app using IVSS.  Why won't it start?"

This question has come up a few times.  Unfortunately, Dependency Walker can't answer it.  And the issue probably won't reproduce on the developer's machine if he has the full SourceSafe 2005 installed.  So let's spell it out:

  • regsvr32 /s ssapi.dll
    • SSAPI is the core VSS library.  None of the VSS clients (command line, SourceSafe Explorer, Visual Studio, IVSS) will work without it.  Registering it with COM is only necessary for IVSS -- the other 3 use proprietary entry points.
  • copy 1033\ssui.dll
    • SSUI holds the localized strings for SSAPI.  1033 is the LCID for English - United States.  If you bought a non-ENU version of SourceSafe, your *ui.dll will live in a different folder (and have different contents, of course).  Look in %programfiles%\Microsoft Visual Sourcesafe† to be sure.
    • The LCID folder must be relative to ssapi.  It doesn't matter where you put it, so long as it's underneath the place you put ssapi @ the time you registered it.  I don't know the exact details of how this works; refer to your favorite COM book.
  • gacutil /f /i Microsoft.VisualStudio.SourceSafe.Interop.dll
    • The Interop DLL is the wrapper that lets you access our COM automation API from managed languages like C#.  If your application uses unmanaged code, you can ignore this step.

†The first half of this path is localized; the second half is not.

Comments

  • Anonymous
    May 23, 2007
    Is there a running service when using VSS? what would be the admin overhead? data volumes?

  • Anonymous
    May 24, 2007
    The comment has been removed