BUGBUG: poor title : vss

SourceSafe 2005 Update is available for download!

Richard Berg — Wed, 12 Dec 2007 04:27:41 GMT

I'm very pleased to announce that the wait is over. Today the first official update for SourceSafe 2005 went live on the web. Download away -- it's only 3.5MB.

To quickly bring new readers up to date: this update is a rollup of 64 VSS bug fixes. We focused hard on customer pain points; almost 3/4 of these fixes came directly from people like you filing bugs on Connect and/or calling Customer Support. The result is a variety of improvements to performance, stability, and reliability, plus a few long-time annoyances. In addition, we focused on compatibility with VS 2008 and Vista. I've gone into detail on those topics before so I won't repeat myself.
VS2008
Vista part1 part2

On the other hand, if you've stayed up to date with our VSS releases and are currently running the CTP, there's still plenty here for you.

full support for all 6 languages (English, Japanese, French, Italian, German, Spanish)
no manual install step
7 extra bug fixes, including some we thought were severe enough to push back this ship date twice :)

VS 2008 and SourceSafe Q&A

Richard Berg — Tue, 04 Dec 2007 01:25:56 GMT

My post about VS 2008 and the SourceSafe CTP generated lots of questions. I'll do my best to answer all of them.

Q: Why wasn't this information in the VS2008 README?
A: It should have been. It was definitely in the Orcas Beta1 and Beta2 READMEs. I haven't checked the RTM copy but if it was missing then that's a mistake and I apologize.

Q: Is VSS2005 the official product for VS2008, or is there a VSS2008 around the corner?
A: Yes, VSS 2005 is still the official source control product in the 2008 time frame. (Along with TFS 2008 of course.) There is no VSS 2008. As you've probably noticed, VSS does not ship every time Visual Studio does. For example, VSS 6.0 shipped way back in 1998 with the VB6/VC6 suite of products, and then shipped service packs (6.0c, 6.0d, etc.) with the next few Visual Studio releases. Will there be another major revision of VSS? That's too far away to forecast -- it depends on how the market looks in a few years.

Q: Does SourceSafe 6.0d work with Visual Studio 2008?
A: SourceSafe 6.0d is not officially supported with VS 2008, nor with VS 2005 for that matter. However, it should be possible to get it working if you're willing to accept some limitations. The quickest way is to run "regsvr32 ssscc.dll" from your VSS6\win32 folder.

Q: Where do I get VSS2005 anyway?
A: If you have a Team Edition of Visual Studio 2005 or later, then VSS2005 is included in your license. It was included on the VSTS 2005 set of discs; you can also download it from MSDN. If you have a Professional Edition of Visual Studio or lower then you need to purchase VSS separately.

Q: What's up with all the TLAs?
A: I agree "VSS GDR CTP" is silly. In recent posts here and on the forums, I've taken to calling it simply "the SourceSafe CTP." There's no danger of being ambiguous, because I'm never doing a CTP again ;) -- contrary to Joel's comment, it ended up requiring just as much testing as a real service pack, so there's not much point. Ideally, I'd rather deliver fully-baked updates early and often than wait for another 64 bugs to pile up. Hopefully the DevDiv Hotfix Availability program will keep us moving in the right direction.

As for the final GDR, its official name will be "SourceSafe 2005 Update." Much better. If we do another one, I'd like to see an even simpler naming scheme, such as "SourceSafe 2005b" -> "2005c" -> etc. Internal processes will probably still force us to call them GDRs, but there's no reason to confuse the rest of the world. What do you think?

List of SourceSafe bugfixes updated

Richard Berg — Tue, 20 Nov 2007 00:35:41 GMT

Just a quick note to let you know that I've updated the list again.

To recap: you can get fixes #1-57 today via the CTP build. English only, I'm afraid. The final GDR ships later this year in all supported languages (English, Japanese, French, Italian, German, Spanish).

VS 2008 users: remember to download the SourceSafe CTP

Richard Berg — Tue, 20 Nov 2007 00:23:28 GMT

You've probably all seen Soma's announcement that the 2008 suite of products officially shipped this morning. Good luck downloading -- our servers are pegged :)

If you plan to use VS 2008 with SourceSafe, make sure to pick up the Update CTP too. Without it, some features like "Open from Source Control" will not work at all. Pay close attention to the install instructions as well. As it says in the KB article:

You may receive error messages when you use Visual Studio 2008. This problem occurs because some compatibility fixes require the Tdnamespaceextension.dll file to be reregistered after you install Visual Studio 2008. To reregister the Tdnamespaceextension.dll file, type the following command at the [elevated - RB] command prompt:
regsvr32 "%programfiles%\Microsoft Visual SourceSafe\tdnamespaceextension.dll"

Sorry about the manual install step. It sucks, I know. The next Update won't have this requirement. (We wanted to ship it before Orcas but ran into some last-minute delays. Expect it before the end of the year.)

Why does SourceSafe need an update anyway? Aren't VS plugin interfaces supposed to be backwards compatible? Yes, they are. In fact, there are no changes to the MSSCCI API in 2008; none of the fixes are related to MSSCCI. (3rd party source control developers can now breathe a sigh of relief). The changes come from the way SourceSafe implements Open from Source Control, Add to Source Control, and Share inside Visual Studio.

Starting in VSS 2005, these functions let you browse the database inside VS's open/add dialogs instead of hanging off the File -> Source Control menu like most other source control providers. It's a cool trick known as a namespace extension. In VS 2008, as you may have noticed, those open/add dialogs got a facelift: like VSS 2005, VS 2008 now uses the standard Windows dialogs. So Vista users in particular get a spiffy new one with integrated search & everything. Unfortunately, that change broke us pretty badly, leading in one way or another to at least 10 of the bugs on my list. Bottom line, you don't want to be caught without the Update linked above.

Hopefully these fixes demonstrate our commitment to keep SourceSafe 2005 a viable option with VS 2008, Vista, and beyond!

SourceSafe Explorer: what does the "build tree" checkbox do?

Richard Berg — Tue, 25 Sep 2007 00:09:28 GMT

When you run Get on a folder (aka project) in VSS Explorer, you're presented with these options:

(if you don't get this dialog, try holding Shift)

Most of the options are obvious, but not "build tree" -- at least not to me. The online help explains it thusly:

Projects only. Overrides the working folders for the subprojects in a recursive operation and builds a project tree on your local computer that mirrors the database project organization. Working folder settings for individual subprojects are ignored. This option is available only when you select the Recursive check box.

Decent explanation -- but if frequent customer inquiries are any guide, it would really benefit from a concrete example. Luckily, Patrick McCormick gave a great one last time the question came up. I've dressed it up with screenshots for added clarity. Let's start with a simple database.

If I run Get on the root ( $/ ), "build tree" will ensure that the file structure created on disk looks the same.

Ordinarily, the "build tree" checkbox is not necessary to get this result. However, it's possible to set explicit working folders in SourceSafe. Working folders might point to completely different locations on disk. If you previously worked with our two WindowsApplications separately it's not likely they map to sibling folders (unless you were very careful). Moreover, if you normally use the Visual Studio IDE, you would never notice because VS uses its own "bindings," not the mappings from VSS Explorer. Thus, you might have inadvertently set up mappings such as

$/WindowsApplication1 -> c:\users\richard\documents\WindowsApplication1
$/WindowsApplication2 -> d:\vss\WindowsApplication2

So long as you're working with these projects independently, that's no big deal. But if you're fetching both of them as part of the same Get operation, there's a good chance you intend to build them together, which means their relative path becomes important. That's the scenario "build tree" intends to enable.

Did you know? How to bring up old-style dialogs in SourceSafe 2005

Richard Berg — Tue, 11 Sep 2007 23:38:15 GMT

One of the changes made between VSS 6.0 and 2005 was to replace ancient file dialogs with common dialogs from the Windows Shell wherever possible. Check out the 6.0 version of Set Working Folder:

It just screams "Win 3.1", complete with floppy diskette icon in the dropdown. By contrast, if you install VSS 2005 on Vista, we can give you a shiny new dialog with no extra work:

There's a secret though: all the old dialogs are still around (in ssgui.dll to be exact). To access them, hold the Shift key as you click the appropriate icon or menu item.

Why should you care? Maybe you have lots of nontechnical users and no training budget. (You devs out there would be surprised how many executive admins, paralegals, HR reps, etc. use VSS to store documents. There was no SharePoint in 1995.) Maybe you rely on UI automation to perform repetitive source control tasks. (As you've probably noticed, not all VSS Explorer functionality is available from the command line and/or IVSS.) Or maybe you're just nostalgic.

Actually, I picked Set Working Folder for a reason. The Windows Browse For Folder dialog has one limitation that the baked-in original did not: you must select a valid folder before the OK button is enabled. Using the old dialog, you can erase the text box and press OK to remove the working folder from your mappings. If you only had the 2005 functionality, you'd be forced to hand-edit the sparsely-documented ss.ini file (yuck).

This post is dedicated to Sara Ford's awesome VS2008 Tip of the Day series.

Back from Brazil

Richard Berg — Tue, 07 Aug 2007 04:02:00 GMT

I've been on vacation the last two weeks, and was silent for several weeks before that. Lots of things from that time stretch I want to share. Most notably, we wrapped up the promised "VSS GDR CTP". Brian Harry was kind enough to announce its RTW in my absence (including an all-too-necessary jab at its TLAs):

Along with the VS2008 wave of products, we are providing an update to Visual SourceSafe 2005 called a GDR. GDR stands for something like General Distribution Release and it is very much like a service pack. The differences are subtle and I won't try to explain them right now. This GDR contains over 57 fixes and includes all customer requested hot fixes and many internally found and fixed issues. It is also designed to make sure that VSS 2005 works well with the VS 2008 wave of products. The update is available for free to all licensed VSS 2005 customers.
We have just released a Community Technology Preview (CTP) for the GDR - ok, the TLAs are getting out of hand now :) You can read about some of the issues it addresses in the following Knowledge Base article: http://support.microsoft.com/kb/939808. And you can download the CTP here if you want to try it out: http://www.microsoft.com/downloads/details.aspx?FamilyID=faf41edd-924d-449f-aefc-9c86dd499720&displaylang=en
The official release of the VSS 2005 GDR will come this fall.

You can find a longer explanation of the terminology and the complete list of bugs among my previous posts. Still, I have quite a blogging backlog from "going dark." First order of business: update said bug list. (edit - done)

SourceSafe 2005 GDR first release around the corner

Richard Berg — Wed, 06 Jun 2007 19:04:33 GMT

We finally have a name. Last time I blogged about the future of SourceSafe, I had to constantly refer to "the next servicing release." No more. That next release will officially be a "GDR" -- and it's coming sooner than you think.

Some brief history on Developer Division nomenclature. Hotfixes are one-off solutions to a specific problem: they are tested briefly, then given directly to customers. A knowledge base article is written to document their existence, but the hotfix itself is not posted publicly; customers must call support to receive them. They are not normally cumulative. (We make VSS hotfixes cumulative since redeploying the whole product only takes about about 4MB. Wouldn't work for Visual Studio, obviously.) Service packs contain a large number of fixes. They are tested very thoroughly by the entire QA organization across our entire matrix of configurations; they receive a full security review; they are localized into every language we support; and so on. SPs are posted on the main MS download page where anyone can get them instantly. They are always cumulative.

A GDR is somewhere in between. They typically contain one large fix, or several related fixes, and receive a moderate amount of testing. As it turns out, our GDR will contain a lot of fixes -- more than some SPs. I hope to share the list with you shortly. It will probably be posted on Connect: anyone can download it, but they must first register with the website (via Passport) so that downloads can be tracked. We're also investigating whether we can leverage Microsoft Update for broader visibility.

Given that background, I'm happy to report that the DevDiv release team accepted our bid to distribute in GDR form. Sorry to add yet another TLA to your vocabulary. On the bright side, what this means is that we can deliver a very broad range of fixes to you without much of the overhead that accompanies a SP. (Those of you who waited...and waited...for Whidbey SP1 know what I mean.) We don't have the resources to commit that kind of effort to SourceSafe.

At the same time, we do want to continue raising the quality of the product. It will be tested across five core languages: Japanese, French, Italian, German, and Spanish. It will be supported on all platforms, including Vista and Orcas, giving a high priority to compatibility issues. Best of all, it will be released early and often for your feedback, as promised. The volunteer testing program described therein is already underway. If all goes well, we'll release a CTP in just a few weeks! (English only) As for the final release, I'm going to keep the goalposts at "later this year" for now :)

Intro to Solution Binding in TFS, plus bonus FAQ

Richard Berg — Tue, 05 Jun 2007 04:10:11 GMT

Solution Explorer isn't working the way I expect. How do I fix it? In TFS, the answer is usually quite simple, because TFS uses workspaces to do most of the dirty work. So if you're familiar with our workspace model, a quick behind-the-scenes tour of solution binding should equip you to solve most problems yourself. (If not, start here).

You may have heard the best practice "always use the Add To SCC / Open From SCC features the first time you work with a solution." The reason is that these features handle all the extra work needed to make sure Solution Explorer, your source control provider, and the integration between the two is initialized and talking to each other happily. Let's take a high-level peek inside Add To SCC, which must perform 3 main tasks:

See if the root of the project / solution is mapped

If so, do nothing
If not, prompt the user for a new mapping

Pend Adds on all child projects & files as necessary
Record the mapping into the *.sln and *proj files. Such entries in the sln/proj files are known as "bindings". They are what tell Solution Explorer to activate its Source Code Control Integration (SCCI) features: special status glyphs, adding Checkin/Checkout to the context menu, etc.

Immediately, we can see why using Source Control Explorer or the tf.exe command line to add your solution won't turn on SCCI -- you skipped step 3, and possibly step 1 as well. So how do you fix it? The answer lies in the mysterious Bind dialog.* (File -> Source Control -> Change Source Control)

I'm actually stealing an image from VSS here. In VSS and many other source control providers, this is where you configure your local <-> server mappings, control which projects are online vs offline, and otherwise manipulate bindings. In case VSS users are wondering -- yes, VSS does have its own "working folders" but they are too fragile for this purpose.

TFS, on the other hand, does use its internal mapping scheme (workspaces) for this task. As a result, all buttons are disabled except Bind/Unbind and Refresh. The "advanced bind dialog" (what you get when clicking a single row, then clicking the "..." that appears underneath Server Binding) is also gone. When you click Bind, TFS will ask your current workspace what the server name of the sln/proj file is, then blindly write that into the bindings. Depending on whether those files actually exist on the server, it may or may not come up Valid. If not, you can't fix it from here. It's all controlled by the workspace.

I know, tight coupling with a totally separate dialog doesn't sound good. But trust me, it makes life easier. As we'll see in the Q&A section, virtually all problems can be solved by the same advice: fix your workspace and rebind. So if you understand workspaces, you're set. Meanwhile, fixing VSS bindings requires you to grok weird Visual Studio-specific concepts like "unified binding root." See Alin's awesome explanations:
http://alinconstantin.members.winisp.net/webdocs/scc/Bindings.htm
http://alinconstantin.members.winisp.net/webdocs/scc/VSNetVC6.htm

Let's summarize what we've learned so far by mimicking the Add To SCC feature on our own.

Bring up the Workspaces dialog. Type 'tf workspace <wsname>' or use the dropdown in Source Control Explorer. Verify that all the projects you're trying to add can be mapped onto a server path. If not, add an additional mapping.
Pend adds on your files. 'tf add <solutiondir> /r' will do it, as will the Add dialog in SCE.
Bring up the Bind dialog.* Highlight all rows and click Bind. If you did steps 1-2 correctly, they should all light up as 'Valid'.

(VSS users take note: at this point you need to save & Checkin. The files are only pending Add, not committed to source control yet).

We're now equipped to answer some common questions.

Q: I added all my code to TFS. When I opened one of my solutions from disk, Solution Explorer didn't show any SCCI / I got an error. How do I fix it?
A: Bring up the Bind dialog. If there are any old bindings there (e.g. to a previous source control system), use the Unbind button to remove them. Once everything is unbound, highlight all rows and click Bind.

Q: I moved my solution to a different location on disk, now SCCI doesn't work. Why?
A: You should've used the Workspace dialog to move the folder(s) for you. Tf.exe and Source Control Explorer won't work until you fix your workspace. Do so and SCCI will be happy too.

Q: I want to add a new project, but Add Project To Source Control is not an option on the context menu! What gives?
A: Chances are that project file already has bindings of some sort. Bring up the Bind dialog. Unbind + Bind should fix it.

Q: There's an extra mapping in my workspace that I don't remember adding. Where did it come from?
A: If you ran the Add To SCC wizard, and one of the projects wasn't mapped in the current workspace, then you probably got a dialog like this one:

What you may not have realized is that your choice resulted in a new mapping from the specified local folder to the server path you chose.

If you used Open From SCC, we will actually add missing workspace mappings automatically.

That's all for now. Next time, some limitations of this model.

*Two caveats. First of all: no, you aren't blind, it's really the "Change Source Control" dialog, but nobody calls it that. Sorry. Second, since we're starting from scratch here, make sure you have the correct SCC plugin selected in Tools -> Options -> Source Control.

Deploying SourceSafe automation on clean machines

Richard Berg — Thu, 10 May 2007 00:34:54 GMT

"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.

A few good men: the next SourceSafe servicing release, recruiting, and you

Richard Berg — Thu, 03 May 2007 08:56:40 GMT

Many of you have wondered aloud when VSS 2005 SP1 will finally arrive. I can't answer that yet, because the answer may be "never." Fortunately, that's just semantics, as we'll see in a moment. I do have some information for you today -- all of it good -- as well as a way you can help.

Why "the next SourceSafe servicing release"? What kind of name is that? It isn't one. The truth is we don't know yet whether this set of fixes will be released as SP1, a GDR, or a hotfix rollup. In the past, on the forums you may have seen me refer to fixes being "included in SP1" or "VSS GDR". No more. I don't want to release a lowly hotfix rollup that has everything I promised for "SP1" & more, only for people to say thanks, but when is the real SP1 coming? due to name confusion. Same thing with the so-called "preview release" (aka CTP, SP1 beta, GDR beta, etc.) So annoying vague names it is. On to the news.

We will ship a SourceSafe servicing release later this year. No, I don't anticipate it'll take us until 12/31/07 to deliver the fixes you guys need...just hedging my bets in this very public forum. In fact, to some degree, we need community participation early & often. This will happen via two avenues:

(1) We will ship at least one preview release before the final servicing release. I don't know yet whether this will be publicly available @ downloads.microsoft.com or if we'll go through MS Connect. If you have strong feelings one way or another, let us know.

(2) We will convene a small group of volunteers to test builds more frequently. If you're willing to try prerelease builds, please leave a blog comment or use the 'contact' button. I can start collecting contact info immediately, with the aim to deliver the first builds within the month. I think these builds are already higher quality than 2005 RTM, with nowhere to go but up...IMHO of course. Nevertheless it's important to caution that they have not been tested very extensively. We're recruiting some internal customers as part of this program, but the fact is there isn't much VSS dogfooding within Microsoft. Furthermore, these builds will probably not include prefabbed installers / uninstallers and certainly won't have dedicated webpages, READMEs, etc. that official CTPs and Betas do. Of course, we will help you install them and troubleshoot any problems you encounter. Because it will be relatively hands-on, I must limit this program to 5-10 people max, sorry.

SourceSafe users, update your bookmarks! Alin Constantin's homepage has moved

Richard Berg — Wed, 02 May 2007 21:10:00 GMT

Power users should be familiar with the great work Alin did during his time on the SourceSafe team. He was one of the most active forum participants and compiled a great set of tips on his personal website. Not to mention his extensive development on the product itself.

Until now, his website was hosted on his own server at home via dynamic DNS. While it was surprisingly stable considering the circumstances, it was hardly the place for such useful info. Any time his ISP went down or he rebooted the machine, we'd get desparate emails from customers or even internal MS support engineers. Luckily, we can now lay those to rest. Microsoft Visual SourceSafe and Visual Studio source control integration help and tips now has a permanent home. Topics covered:

Microsoft Visual SourceSafe and Source Control resources
Installing and configuring Microsoft Visual SourceSafe for Internet (Remote) access
About Visual SourceSafe Passwords and Security
Source Control Bindings explained
Microsoft Source Control Interface
.root folders explained
Is Source Control integration really worse in VisualStudio .NET than in Visual C++ 6.0?
Renaming and deleting files in projects under source control in Visual Studio (the good, the bad and the ugly)
The SUO file and Web Projects in VisualStudio .NET
Files used by source control integration in VisualStudio .NET
I got an "Unspecified error" message in VisualStudio .NET, what now?
Using Visual SourceSafe 6.0 with Visual Studio 2005

Be sure to check it out if you never have. There's also some new content, such as Vista instructions & screenshot in the Remote Access article.

DST 2007 issues in SourceSafe

Richard Berg — Mon, 29 Jan 2007 23:37:06 GMT

The rules for U.S. daylight savings time are changing in 2007. SourceSafe cares about time zones, so you should too. Complete details are in KB article 931804. To quote one section heading, "If you do not update the servers and client computers, you may lose check-in information".

There, do I have your attention now? :)

[Thanks to everyone who helped put this article together. People inside & outside of MS often complain about the difficulty of maintaining the KB -- rightfully so in some cases. This article went from idea to the web in under a week, so it can be done!]

SourceSafe on Vista part 2

Richard Berg — Fri, 26 Jan 2007 22:38:51 GMT

I want to expand on the Microsoft support lifecycle policy I mentioned before. To reiterate, VSS 2005 gets "mainstream" support for quite some time while 6.0 will enter "extended" this July. I won't repeat everything in the support doc (read it!). Bottom line, the bar for non-security hotfixes to 6.0 is a lot higher. Furthermore, there are no more service packs planned beyond 6.0d. Not a lot happens in that codebase without an Extended Hotfix Support Agreement and a lot of prodding.

So what the heck did I mean by "full Vista support" then? Well, if a blocking issue surfaces, you can be sure one of the customers who paid good money for their Important Contract With Long Name will call us up and request a fix. Once a "QFE" has been released, anyone can get it from CSS at no charge. With luck, we'll even be able to post it to the web. As for non-blocking issues...I will never say "never", because every situation is different. Suffice to say if the transparency of some 6.0 control under Aero is a little bit off, that's going to be a tough sell.

2005 is a different story. I encourage everyone to file bugs -- Vista compat and otherwise -- early and often, because until we ship the first servicing release "the bar" is as low as it will ever be. Personally, the developer in me wants to see every last niggling bug fixed, and right now is the best time for that to happen. We will also continue to take QFEs from customers that bubble up through the support process, as well as participate in the Developer Division's ongoing development & stabilization processes. For instance, we've already had to fix one major compatibility issue with Orcas...if you take the January CTP for a test drive on a Vista box and try to Open From Source Control, you'll see what I'm talking about :(

I can't promise to fix every last bug, obviously. As we draw closer to actually delivering these improvements to you, we'll make the inevitable tradeoffs between releasing everything "someday" vs releasing "enough" on time and thoroughly tested. (Granted, managing a product that's in servicing mode strikes me as a rather unique POV among the myriad SDLC writers out there. A future blog topic, perhaps.) Still, that only underscores the need for us to know about the issues ASAP, in order to make the most informed decisions. In addition to Connect bugs, feel free to post to the forums or the comment section on this blog. Don't be shy!

Clarifying SourceSafe support on Vista

Richard Berg — Tue, 23 Jan 2007 11:16:11 GMT

Amid all the furor over Whidbey SP1 and the forthcoming Vista GDR, there hasn't been any statement on what it all means for SourceSafe users. Rest assured we have some official KB articles in the works. But I think it's important to share this info with the community as soon as possible -- if anything I'm a few months late to the party -- so here goes.

Bad news first. You cannot host the SourceSafe 2005 web service on Vista. Unfortunately, this limitation is beyond our control. Unlike previous versions of IIS, the one found in Vista does not include a WebDAV component. The IIS 7.0 team only began work on this feature near the end of Vista's ship cycle, planning to target the 'Longhorn server' release instead.

WebDAV is an extension to the HTTP protocol that allows you to treat a webserver like a remote store. The VSS HTTP service uses the PUT method to upload files. Rearchitecting that is way outside the scope of what we can do in servicing, regrettably. All hope is not lost, though: it's possible that a 3rd-party DAV plugin could fill the gap, and/or that the LH Server pieces will find their way into a Vista service pack. I'll keep you updated as we investigate these options.

Meanwhile, let's explore exactly what this news implies for users.

You can still host a VSS database on Vista. The ordinary fileshare-based VSS protocol works fine. In fact, I was pleasantly surprised to find that there are no workarounds, hotfixes, UAC hacks, or anything of the sort required; the setup steps are identical to XP or 2003, modulo some redesigned shell dialogs.
If your VSS database is on a Vista machine, you can still use HTTP! You just need to put the HTTP service on a different box (or a VM). Again, this scenario is 100% supported with no extra work.
The "official" best practices story has not changed. It has never been recommended to host a VSS database on a client OS. Even XP and 2000 Pro had some serious limitations in their implementation of IIS, most notably a 10-connection cap. (In practice, of course, lots of people do it anyway. After all, the main selling point for SourceSafe is getting small teams up & running instantly.)

I saved the good news for last. We remain committed to supporting the VSS clients on Vista & all future client OSes, and likewise the VSS server pieces on server OSes, for the duration of their support lifecycle. As you can see from the chart, VSS 6.0 has extended support thru 2008; VSS 2005 has mainstream support thru 2010 and extended thru 2015. Like I said, I haven't come across any problems yet...if you find one, you only have about 9 years to report it, so don't delay ;)