project-system: Please fix the .vspscc problem

{ProjectName}.vspscc files continually get recreated in each project folder and are now shown in Solution Explorer. It has been irritating enough that they have to exist in the first place, and continually get added to pending changes even though the contents never change and are all in fact identical with each other. Now we have to look at them in Solution Explorer or add boilerplate to every new csproj we create, which is almost as bad because we shouldn’t have to dirty everything. The vspscc files should not exist in the first place.

https://social.msdn.microsoft.com/Forums/vstudio/en-US/9920911d-1a7e-4ada-90cd-b1b910586cf4/why-do-you-need-the-vspscc-and-vssscc-files This was acknowledged by Microsoft in 2005; in 2010 “We are looking into improving this in the future version of Visual Studio”; now, especially with the new csproj format, please do the right thing and cut these files.

All ignored files are handled via .tfignore. These files are purely vestigial and are irritating on a daily basis.

Every single .vspscc has precisely these contents which never change, even though the files show up in Pending Changes all the time:

""
{
"FILE_VERSION" = "9237"
"ENLISTMENT_CHOICE" = "NEVER"
"PROJECT_FILE_RELATIVE_PATH" = ""
"NUMBER_OF_EXCLUDED_FILES" = "0"
"ORIGINAL_PROJECT_FILE_PATH" = ""
"NUMBER_OF_NESTED_PROJECTS" = "0"
"SOURCE_CONTROL_SETTINGS_PROVIDER" = "PROVIDER"
}

About this issue

  • Original URL
  • State: open
  • Created 7 years ago
  • Reactions: 52
  • Comments: 32

Most upvoted comments

VS 2017 (15.5.1) wants to put them into source control for me right now, in a server work space. I’ve been waiting for this annoyance to go away for about 10 years now.

image

image

Also when we update NuGet packages, if the vspscc file hasn’t been added to TFS every project being updated results in a warning dialog popping complaining it can’t check the vspscc fiel out. So we have to go through 180 projects and manually add the vspscc file.

Using Git is not a solution. Git has it’s own issues, and should never be used in an environment where you require “Cherry Picking”. It is extremely limited in what it can do, and will cause you merging nightmares. If your company is ISO 27001 certified, you might want to consider all of the hurdles that you’ll need to overcome, before switching away from a “standard” source control system.

If you require the use of cherry picking on a regular basis, you’re doing it wrong and your real issue is the branching and merging strategy you have chosen, not the SCM you use. Blaming git for having poor support for a scenario that is only problematic because of poor choices your company has made is disingenuous, to say the least.

git is not my favourite SCM by a long shot, but it is streets ahead of TFS; even Microsoft has implicitly acknowledged this. You can either continue to complain (effectively into the void) that Microsoft is no longer focusing on a legacy product, or you can consider entering the 21st century by switching to a modern SCM that is supported by pretty much everyone and everything.

Your choice.

Using Git is not a solution. Git has it’s own issues, and should never be used in an environment where you require “Cherry Picking”. It is extremely limited in what it can do, and will cause you merging nightmares. If your company is ISO 27001 certified, you might want to consider all of the hurdles that you’ll need to overcome, before switching away from a “standard” source control system.

The error in this case is: The item [path][project].vssscc could not be found in your workspace, or you do not have permission to access it. [project] could also be [solution], depending on which you are saving.

I suspect the deafening silence from Microsoft regarding this issue essentially translates to “we don’t care enough about TFS any more to fix this, if you have a problem use git”.

edit: a sentiment which I totally agree with.

No but it stops me having to press ‘OK’ on 50 buttons.

so my questions are: who at Microsoft do I address to change mindset that messageboxes are an acceptable user experience? where do I provide feedback to the Visual Studio team (with actionable examples) that won’t get auto-closed? who at Microsoft do I address to remind them that regressions in TFVC should actually be fixed – and not auto-closed – and that there are large Fortune 500 companies that still have millions of dollars of assets in TFVC and should not be forced to budget the hundreds (possibly thousands) of man-hours that it would take to convert to git for no business value return?

(asking for a friend 😉 )

Git has issues for sure, but based on my experience, I would have said that a reason to move from TFVC to Git is the merging nightmares in TFVC that you can avoid with Git. I also use cherry picking and it seems reliable. Your experience is definitely just as valid. Just making sure folks know that this is not a black and white situation by any means.

Please, find and eliminate ALL MessageBox popups from the VS source control providers!!! Please direct ALL source control output to the Output window – reserve popups for ACTUAL errors. a missing vspscc is NOT an actual error – it is an annoyance and the madness needs to stop.

BTW, this seems to have gotten worse with VS2019… I can say my frustration level has significantly increased from VS2017 – almost entirely because of pop-ups in various areas. MESSAGEBOXES ARE NEVER A GOOD USER EXPERIENCE!

I get that error from time to time, usually when I “go online” after I’ve been disconnected from TFS, but sometimes during a NuGet operation too.

Visual Studio 2017 does not add them. However, we noticed that executing a Save (CTRL+S) generates the error, where a Save All (CTRL+SHIFT+S) does not generate the error (and allows changed files to be checked in). It seems to be a Visual Studio UI issue then

Visual Studio 2017 is no longer adding these files to TFS. However, if there is any system that is still requiring these file exist, and for no other reason than to exist, that needs to be fixed. I’ve looked at all the threads since 2005 and not one person from Microsoft could explain their use. The only thing that I did find is that they had an intended purpose of containing files to exclude from source control, but that purpose never manifested.

Just to be clear, I recommend moving to Git while acknowledging that this certainly does not solve the problem nor is it possible for everyone.

@StingyJack I have never seen .vspscc in Git repos unless they were copied in from TFVC repos, and I’ve been using Git with TFS/AzDO for years.

Git is widely used and well understood for real work. Microsoft uses Git for the Windows codebase, all the .NET tooling such as the C# compiler and the IDE, the runtime itself and the base class library, etc. Git has critical advantages over TFVC. In TFVC, branching is painful and reviews can’t be done on a sequence of small changes, only on one big changeset that flattens all changes. Git has something better than shelvesets: a concept of branches that is so lightweight that branches become a powerful tool. Every Git repo hosting platform like Azure DevOps has a concept of protected branches, so rewriting history is rarely a real-world concern. It’s terribly useful to be able to rewrite history within your own short-lived branches prior to review, though.

If you are willing to edit it delete that, I’ll do the same for this paragraph.

I don’t believe my comment is off-topic. Microsoft’s lack of priority for TFVC (and dogfooding of Git rather than TFVC for their most important projects) is a signal of interest to the folks waiting for a resolution to this issue.

I would recommend converting everything to Git, for this reason and other reasons. I used https://github.com/git-tfs/git-tfs and https://github.com/Techsola/tfvc-migrator.

@burtonrodman I don’t think this is the right thread to report that issue. I’d use the VS feedback tool since I’m not sure that is an issue contained in the dotnet/project-system codebase.

@jaans. Yes add them to TFS. It’s the only way.

Definitely want/need client side workspaces. I think it’s not just NuGet either; touching project references at all seems to do this IIRC.