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 https://github.com/Microsoft/msbuild/pull/1607, https://github.com/dotnet/sdk/issues/522

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

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.

[roji]

@davkean and others, can you please clarify what the right behavior here should be, and which GUID should be used when a new .NET Core (new csproj) project is created?

I ran into this with Project Rider, which create new .NET Core projects with FAE04EC0, but VS switches them to 9A19103F. Which GUID should Rider (and other IDEs) be creating?

https://youtrack.jetbrains.com/issue/RIDER-14653

[roji]

@davkean @natemcmaster ping, would it be possible to get guidance here on the correct behavior for JetBrains Rider (https://youtrack.jetbrains.com/issue/RIDER-14653)

[davkean]

Sorry for the late reply.

The following GUIDs should be persisted:

Language	GUID
C#	FAE04EC0-301F-11d3-BF4B-00C04F79EFBC
Visual Basic	F184B08F-C81C-45F6-A57F-5ABD9991F28F
F#	F2A71F9B-5D33-465A-A702-920D77279786

We have a bug that we are switching these GUIDs from above to different ones, which will be fixed for 15.8.

[davkean]

Microsofties, I suspect this will fix this: https://devdiv.visualstudio.com/DevDiv/_git/CPS/pullrequest/122409?_a=overview.

[SwooshyCueb]

I've had VS change a GUID for a non-sdk C# project to the 9A19103F GUID, so I don't think it's limited to just sdk projects.

[davkean]

Our rules for opening projects are specified here: https://github.com/dotnet/project-system/blob/master/docs/opening-with-new-project-system.md. If any non-SDK projects match the patterns called out in that doc then they will be opened in new project system.

[davkean]

I've been testing my change above, it does indeed prevent the solution from changing the project type for C# projects from FAE04EC0-301F-11d3-BF4B-00C04F79EFBC -> 9A19103F-16F7-4668-BE54-9A1E7A4F7556. However, it also causes the reverse, changing 9A19103F-16F7-4668-BE54-9A1E7A4F7556 -> FAE04EC0-301F-11d3-BF4B-00C04F79EFBC. This will break "explicit" opt-in into the new project system, so we need to come up with a design that factors that in.

[poke]

Wish I could access the the PR to help out.. :sweat_smile:

But I’m really glad that there’s some progress with this issue. Thank you @davkean!

[paulomorgado]

So, @davkean, if I have to fix a solution by hand, the recommended value for C# projects is FAE04EC0-301F-11d3-BF4B-00C04F79EFBC and not 9A19103F-16F7-4668-BE54-9A1E7A4F7556. Even for SDK projects.

Is that it?

[davkean]

Yes.

[davkean]

Note, if you don't have a TargetFramework/TargetFrameworks property inside the project itself as called out in https://github.com/dotnet/project-system/blob/master/docs/opening-with-new-project-system.md, you have to mark it as '9A19103F-16F7-4668-BE54-9A1E7A4F7556'.

[rtaylor72]

I have a big problem here. I was just upgrading an existing 4.6.1 .NET framework with ASPNET Core to 4.7.1. I started getting errors about mixed frameworks in the packages.config. A solution mentioned was to right mouse click on the project and covert it to package references. This fixed the build errors (VS 15.7.6). But now I am getting weird build errors on my TFS build server like this: "error CS0234: The type or namespace name 'Extensions' does not exist in the namespace 'Microsoft'". I am running with build agent 2.136. I have narrowed it down to any project that I did this convert to PackageReference to actually had already a '9A19103F-16F7-4668-BE54-9A1E7A4F7556' project type (we were tying to do a .NET Core app, but had to fall back to .Net Framework because of 3rd party stuff) and the build server is not dropping DLLs from the Nuget packages into those project folders that have the older GUID causing these weird build errors.

So I am now going to try and change all project files to 'FAE04EC0-301F-11d3-BF4B-00C04F79EFBC' and see if I can (most likely manually for several project files) get this project to build. Hope this helps someone.

[rtaylor72]

My solution was to switch all project types to 'FAE04EC0-301F-11d3-BF4B-00C04F79EFBC' that were '9A19103F-16F7-4668-BE54-9A1E7A4F7556' in the solution file and then convert older project files to the new Microsoft.NET.Sdk format by unloading them, then replacing them with the following template, reloading then, and then re-adding the dependencies back:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup Label="Globals">
    <SccProjectName>SAK</SccProjectName>
    <SccProvider>SAK</SccProvider>
    <SccAuxPath>SAK</SccAuxPath>
    <SccLocalPath>SAK</SccLocalPath>
    <Platforms>AnyCPU;x86;x64</Platforms>
  </PropertyGroup>
  <PropertyGroup>
    <TargetFramework>net471</TargetFramework>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <PlatformTarget>x86</PlatformTarget>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x86'">
    <OutputPath>bin\</OutputPath>
  </PropertyGroup>
  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x86'">
    <OutputPath>bin\</OutputPath>
  </PropertyGroup>
</Project>

[poke]

@rtaylor72

[…] upgrading an existing 4.6.1 .NET framework with ASPNET Core to 4.7.1. I started getting errors about mixed frameworks in the packages.config.

So you had a ASP.NET Core application running on .NET Framework 4.6.1 with packages.config and old-style .csproj files? I don’t think that’s even a supported way to run ASP.NET Core. I believe you need the new Microsoft.NET.Web.Sdk to run ASP.NET Core.

[thomaslevesque]

We have a bug that we are switching these GUIDs from above to different ones, which will be fixed for 15.8.

I still have the problem with 15.8.1. New projects are added with the correct GUID FAE04EC0-301F-11D3-BF4B-00C04F79EFBC, but every time the solution is modified, the GUID for existing projects is changed to 9A19103F-16F7-4668-BE54-9A1E7A4F7556.

[dinobu]

I reported this issue here. Very annoying if you use both VS and VS for Mac https://developercommunity.visualstudio.com/content/problem/304031/project-guid-changes-when-building-in-vs2017-vs-bu.html?childToView=328928#comment-328928

[stijnherreman]

@thomaslevesque Looks like this was pushed to Visual Studio 2019, the miilestone has been changed to 16.0

[Seikilos]

A bit of extra information: We have constant merge issues in our team within git because every new project tend to receive the same 9A19103F-16F7-4668-BE54-9A1E7A4F7556 GUID. So when rebasing the branches to a master where there is already another new project again with the same GUID it always gets conflicted. Since the amount of projects we add is high, it keeps introducing merge issues for weeks now.

[thomaslevesque]

A bit of extra information: We have constant merge issues in our team within git because every new project tend to receive the same 9A19103F-16F7-4668-BE54-9A1E7A4F7556 GUID. So when rebasing the branches to a master where there is already another new project again with the same GUID it always gets conflicted. Since the amount of projects we add is high, it keeps introducing merge issues for weeks now.

9A19103F-16F7-4668-BE54-9A1E7A4F7556 is the project type GUID, it's not supposed to be unique per project... The project id is the other GUID at the end of the line, it's the one that should be unique.

[am11]

In our build machines, we noticed that leaving some projects with 9A19103F-16F7-4668-BE54-9A1E7A4F7556 GUID in a (mixed) solution with many projects causes file-locking build-concurrency issues (and hence build failures), with a significant frequency.

Changing all those GUIDs back to FAE04EC0-301F-11d3-BF4B-00C04F79EFBC in SLN file fixed the issue immediately. TBH, figuring it out required reading and comparing MSBuild diagnostics dumps and lots of ☕️.

[thomaslevesque]

@thomaslevesque Looks like this was pushed to Visual Studio 2019, the miilestone has been changed to 16.0

The milestone has been changed to none, and I still see the problem in VS2019. New projects are added with GUID FAE04EC0-301F-11d3-BF4B-00C04F79EFBC, but the next time the solution file is updated, the existing ones are changed to 9A19103F-16F7-4668-BE54-9A1E7A4F7556.

[sandeepiiit]

@thomaslevesque Looks like this was pushed to Visual Studio 2019, the miilestone has been changed to 16.0

The milestone has been changed to none, and I still see the problem in VS2019. New projects are added with GUID FAE04EC0-301F-11d3-BF4B-00C04F79EFBC, but the next time the solution file is updated, the existing ones are changed to 9A19103F-16F7-4668-BE54-9A1E7A4F7556.

I am also seeing the exact same issue described by @thomaslevesque in Visual Studio 2019.

[fuzzykiller]

Visual Studio 2019 has different behavior depending on the project type GUID, for example with this strange behavior.

It would be great if any change on this topic doesn’t inadvertently break more stuff.

[springy76]

Why can't you fix that annoying bug within 2 1/2 years? Gits auto-merge tends to fuck up .sln files and often you end with two consecutive "Project ..." or "EndProject" lines, which is a big PITA.

Everyone in our company is using newest VS 2019 on Windows, every new project is of type netcore or netstandard, every new project gets added with FAE04EC0-301F-11D3-BF4B-00C04F79EFBC and as soon as anyone changes something unrelated (a project many lines above) all remaining FAE04EC0-301F-11D3-BF4B-00C04F79EFBC silently get changed to 9A19103F-16F7-4668-BE54-9A1E7A4F7556 on .sln file update.

[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 https://github.com/dotnet/msbuild/issues/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 https://github.com/dotnet/msbuild/issues/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.

[davkean]

@springy76 To get rid of the GUID required a bit of a redesign on how this all worked. The rewriting of the solution code to support the new SLNX format has unblocked this, and you will be happy to see that this was addressed in 17.12.