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.