Please fix the .vspscc problem

[jnm2]

{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"
}

[PhilPJL]

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.

[Kaelum]

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.

[jnm2]

VS 15.4 puts .vspscc files in pending changes for me daily. Do you think if I delete them they won't come back?

[Kaelum]

@jnm2 Are you using server side workspaces? Or, client side workspaces? When using server side, it no longer adds the files to Pending Changes. Client side adds all files of virtually all types, with few exclusions. Client side requires manual management, so I don't really know what to tell you. If there is currently an issue with NuGet, then I would say yes, until the issue is addressed. :/

[jnm2]

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

[StingyJack]

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.

[basvedder]

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

[StingyJack]

@basvedder - what error?

[basvedder]

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.

[StingyJack]

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.

[Jaans]

This is so painful. Not only do I have 289 dialogs to OK everytime, but it takes so long inbetween each dialog appearing. A waste of time!

So what is the workaround?
Do I delete them? Do I check them into TFS until such time as the issue is resolved?

[PhilPJL]

@Jaans. Yes add them to TFS. It's the only way.

[Jaans]

@PhilPJL Thanks, that helps! I added the following to our .tignore file in the root to get VS to start including them:

!*.vspscc

[StingyJack]

That's not going to stop VS from checking them out and cluttering up pending changes whenever you update a nuget package.

[PhilPJL]

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

[burtonrodman]

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!

[jnm2]

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

[StingyJack]

@jnm2 at least here it doesn't get auto closed due to lack of interest. The product teams treat defects reported here closer to actual defects that customers need fixing than the "optional background noise" treatment the same report would get on devcomm.

It would be nice if there was still an objective third party hosting these issues to limit unsavory activities or mediate, but there's always the option to report Ethics violations and the like.

[jnm2]

Questions of unsavory activities and ethics are covered by https://github.com/dotnet/project-system/blob/master/CODE_OF_CONDUCT.md.

This thread is tracking a request to stop creating .vspscc files. A request to lower the frequency of message boxes needs its own thread and some actionable examples.

[IanKemp]

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.

[jnm2]

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.

[StingyJack]

@IanKemp pretty sure I've seen these files in git repos also. VS probably respects the .gitignore file, where it does not do so consistently with the .tfignore (and will continue to have these bugs for the same "git kool-aid" reason you stated).

@jnm2 git requires more effort for the same actions, which is fine for hobby projects done on the cheap, but not something I'm interested in when doing real work. It's unclear and inconsistent commands become dangerous quickly since it permits destruction or a rewrite of history (two qualities that shouldn't be present in a version control system). It's biggest gap is that it doesn't have shelvesets. That said, and I know this is your issue and am glad you logged it, but this paragraph is dedicated to responding to an off topic comment. If you are willing to edit it delete that, I'll do the same for this paragraph.

[jnm2]

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

[burtonrodman]

@StingyJack thanks for summarizing my feeling on the state of Visual Studio feedback.
@jnm2 suggesting that people move to git doesn't solve this problem -- there are organizations that have hundreds of projects in various states of maintenance, comprised of millions of lines of code, hundreds of builds, releases, etc.. that cannot just be converted because Microsoft decides it doesn't care about TFVC anymore. All they have to do it stop introducing regressions -- and actually fix the regressions that are reported instead of closing them as "not enough customer interest".

[jnm2]

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.

[Kaelum]

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.

[jnm2]

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.

[burtonrodman]

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 ;) )

[jnm2]

Not sure of the best answers to those questions. The Visual Studio feedback tool is one way. Microsoft support (https://support.microsoft.com/en-us/hub/4343728/support-for-business) is another way. If you're a Fortune 500 company, it seems like there would be other ways you could get in contact with folks at Microsoft.

[IanKemp]

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.

[burtonrodman]

@IanKemp I'm not arguing the merits of git vs TFVC vs et al -- all of my clients see the writing on the wall concerning TFVC and are actively moving to git. My point is that Microsoft should not break some feature in VS related to TFVC with every release and subsequently ignore feedback, while businesses have more important, valuable things to worry about than moving source control systems on projects that haven't been/won't be touched in years.

[jnm2]

@burtonrodman This issue is not about a feature that Microsoft broke, as far as I'm aware. I'm asking for an improvement to get rid of the boilerplate files that have been a pain from the beginning.