Visual Studio and Visual Studio for Mac overwrite each other's changes in the solution

[natemcmaster]

I've seen different project type GUIDs used for C# projects in VS 2017 solutions.

dotnet/sdk and dotnet/cli template and use FAE04EC0-301F-11D3-BF4B-00C04F79EFBC. cref dotnet/msbuild#1607, dotnet/sdk#522

Yet, VS 2017 will sometimes automatically change solution files using FAE04EC0.. to a different GUID: 9A19103F-16F7-4668-BE54-9A1E7A4F7556. cref aspnet/Logging#577 (comment)

I took a peek at the code and found this:

        public const string ProjectTypeGuid = "9A19103F-16F7-4668-BE54-9A1E7A4F7556";
        public const string LegacyProjectTypeGuid = "FAE04EC0-301F-11d3-BF4B-00C04F79EFBC";

So, which one is "right"?

cc @davkean @dsplaisted

[davkean]

Yeah, this is known - but I can't find the bug. I'll use this to represent it. The solution shouldn't be seeing 9A19103F-16F7-4668-BE54-9A1E7A4F7556, it should only be seeing the legacy FAE04EC0-301F-11d3-BF4B-00C04F79EFBC. This is for compat reasons, this CPS proejct is going to eventually take over the FAE04EC0-301F-11d3-BF4B-00C04F79EFBC "project type" completely.

[natemcmaster]

Thanks for clarifying @davkean.

[poke]

Just to clarify: Milestone 16.0 means that the fix for this is expected for the next major Visual Studio release, yes? So no changes are expected for Visual Studio 2017?

Also, since I have vigorously attempted to undo the GUID change everytime VS attempted to change it and this is getting a bit annoying by now: Is there any practical disadvantage we get from using the 9A19 GUID instead of the FAE0 one?

[abock]

We're being bit by this in our shared solution (Visual Studio + Visual Studio for Mac) for our product which contains about 60 projects. We now have a handful of .NET Core/new-style-csproj projects in the solution.

Visual Studio uses the new 9A19103F… GUID when serializing the solution while Visual Studio for Mac uses the legacy FAE04EC0… GUID. This issue leads me to believe that Visual Studio for Mac is actually correct here.

Nevertheless, the two IDEs are constantly reverting each other. Whenever someone updates the solution in VS, we'll end up with a diff consisting of 9A19103F… → FAE04EC0…. Then another team member will update the solution in VSM and we'll end up with FAE04EC0… → 9A19103F….

The fix for this bug being targeted for 16.0 is rather unfortunate. I'd be more inclined to lobby for "fixing" Visual Studio for Mac to use the new 9A19103F… as that can be done much more quickly than waiting for 16.0.

As I think @poke indicates, I suspect a bunch of people have already stopped trying to fight reverting the GUID changes in their solutions and we should probably just settle on the new GUID rather than drag this out through 16.0. This is not an option for us or anyone using both IDEs, as we cannot simply commit to one, since the two actively fight each other.

Finally, particularly that this is already in the wild in 15.x, I can appreciate the small amount of value of the new GUID in the solution file - it's an easy indicator of new-style csproj in a solution without having to actually open the project. And yes, I am that guy who hand-edits solution files more often than I should admit.

[warrenfalk]

I can reproduce this on demand. See below. Can we get this fixed - this makes using VS a huge pain.

As @abock notes above, this bug is a nightmare for any cross platform team. But it's a huge pain for any other team also as VS creates the projects as FAE0 and then rewrites them later to 9A19 requiring constant manual manipulation to merge and fix.

@davkean above says that 9A19 is the bug as it should never show in the solution file, but if you rewrite these to FAE0 manually, VS reverts your change. The only solution is to leave it as 9A19 but as @abock notes, if your team is cross platform, this results in impossible-to-manage thrashing as VS and all other IDEs overwrite each other. If you aren't cross platform you'll probably rewrite all to 9A19 but this too is still an issue because now you've blocked yourself from going cross platform and because VS still adds these as FAE0 first requiring all your devs to either manually edit their sln files after adding a project or perform some ritual to get vs to rewrite the FAE0 to 9A19 which it's eventually going to do anyway.

This makes visual studio a huge pain to use for anyone who decided to use the new project format.

How To Reproduce:

1. Create a new solution with a .Net Core console project (project type in solution file is FAE0)
2. Modify solution (e.g. add a solution folder) and save all (project type is still FAE0)
3. Exit Visual Studio and re-open
4. Modify solution (e.g. add a solution folder) and save all (project type is now 9A19)

[karataliu]

Still having this issue:

VisualStudioVersion = 15.0.27004.2010: creates 9A19103F-16F7-4668-BE54-9A1E7A4F7556
dotnet version 2.0.2 creates FAE04EC0-301F-11D3-BF4B-00C04F79EFBC

Another issue is dotnet cli always adding following configurations, while VS only adds for 'Any CPU'

Debug|x64 = Debug|x64
Debug|x86 = Debug|x86

[warrenfalk]

Just to be clear. VisualStudio creates both - it creates with FAE04EC0-301F-11D3-BF4B-00C04F79EFBC and then at some later date will change it to 9A19103F-16F7-4668-BE54-9A1E7A4F7556

...which makes source control a nightmare. I am not sure why this doesn't get more attention. @davkean seemed to think it was already a known issue back in March and that the 9A19 guid should never be showing up.

[davkean]

Folks, we understand this is an issue and a bug.

Can you help me understand why leaving the GUID as 9A19103F-16F7-4668-BE54-9A1E7A4F7556 for now results in editors thrashing with each other? I wouldn't expect the CLI to touch that GUID once the project is added.

[poke]

Leaving that 9A19103F Guid does not cause issues, no. The problem here is:

• C# projects are always created with FAE04EC0.
• Visual Studio 2017 will at some point (which feels rather random) change the Guid for NET.Sdk projects to 9A19103F.
• According to @abock above, Visual Studio for Mac will change the Guid back to FAE04EC0.
• As we learned in this issue, the 9A19103F Guid is a temporary project type Guid which will eventually be turned back to FAE04EC0 at some point in the future.

So you are basically introducing at least two solution changes after the project has been created for every single project at likely distinct times. So basically, the solution file gets changed all the time for no reason, making a mess in the history.

Also, for what it’s worth, my question from above still hasn’t been answered: We still don’t know whether using one or the other Guid for our projects has a disadvantage over the other. All we learned so far is that this behavior is a bug and that we should have never seen that temporary project type Guid. And bugs usually are a bad thing, so I can totally understand why people (including me) tried to keep the 9A19103F Guid out of their solutions.

[warrenfalk]

Please keep in mind that thrashing back and forth when using other tools isn't the only issue.

Even if your team uses only VisualStudio then they will run into this issue because when a developer initially adds a project in one branch, VisualStudio will write FAE0 at first, so it goes into source control as FAE0. But any future developer modifying the solution will have VisualStudio changing the first dev's lines to 9A19 which will eventually be committed unwittingly, and when this happens on different branches as it often will, the merge conflicts are a huge pain to sort out, blames are wrong, etc.

[davkean]

Just a general thing; we have lots of bugs - those with workarounds and don't affect inner loop (ie something a dev does hundreds of times a day), tend to be prioritized behind those without workarounds and do affect inner loop.

At the time I put this in the 16.0 bucket, I was under the impression that leaving 9A19103F-16F7-4668-BE54-9A1E7A4F7556 in the solution prevented the thrashing. Somehow I missed VS Mac and VS fighting each. This increases the priority and I'll move it forward - make note 15.6 is entirely fully booked, so tentatively putting this in 15.7.

[awasilik]

Hey, I am writing from 2021 and the issue still exist. Is a real pain for our team with source control.
Half of the team is working on VS for Mac and the other on VisualStudio 2019 on Windows and we're working on Xamarin project.

Windows version is modifying sln file changing all netstandard 2.1 projects from FAE04EC0-301F-11D3-BF4B-00C04F79EFBC to 9A19103F-16F7-4668-BE54-9A1E7A4F7556 and VS for Mac is doing the reverse causing us to constantly having to resolve merge conflicts. This is a constant struggle and it is here 4th year.

[springy76]

It soon is another 2 years later since my last comment speaking of 2 1/2 years... now 4 1/2 years.. being on latest VS and net5 and still seeing this sh*t regularily. 👎 and there is not even any Mac involved anywhere.

[kasperk81]

any news?? instead of fixing just this, please allocate resources to fix dotnet/msbuild#1730 with visual studio team and get rid of the guid from sln once and for all. new sln file should look something simple:

example of implicit: <Workspace><Project Path="/folder/file.csproj" /></Workspace>
example of explicit: <Workspace><Project Type="C#" Path="/folder/file.weirdExt" /></Workspace>

without any guid or other garbage data.

[lmorvan]

Please, can you definitively get rid of that solution file format and do something a human can read and eventually debug, and version control systems can merge easily and again in a human understandable way?

[stijnherreman]

@lmorvan that's discussed/tracked in dotnet/msbuild#1730 and https://developercommunity.visualstudio.com/t/Clean-up-sln-VisualStudio-solution-fil/988209 :)

[springy76]

Yeah, this is known - but I can't find the bug. I'll use this to represent it. The solution shouldn't be seeing 9A19103F-16F7-4668-BE54-9A1E7A4F7556, it should only be seeing the legacy FAE04EC0-301F-11d3-BF4B-00C04F79EFBC. This is for compat reasons, this CPS proejct is going to eventually take over the FAE04EC0-301F-11d3-BF4B-00C04F79EFBC "project type" completely.

and 7 years later still every added project starts with one of those GUIDs and later changes to the other when something else changes, or another project gets added.

How f*cking difficult can it be to remove one of the guids or at least ensure only one is used for writing?

For years everyone has been telling its impossible to migrate VS to 64bit... seems have been much easier than getting rid of that fucking guid.