Old project type GUID are used for new projects/solutions

[beppemarazzi]

Visual Studio Version

Version 17.12.2

Summary

C# projects targeting .net 9 are added to sln using "old" project type GUIDs

Steps to Reproduce

1. Create a new console app c# project OR add a class library to an existing solution
2. Open the .sln file with a text editor
3. Look at the lines starting with Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = ...

Expected Behavior

the project type GUID is expected to be Project("{9A19103F-16F7-4668-BE54-9A1E7A4F7556}") = ... as documented here https://github.com/dotnet/project-system/blob/32c88de3973358cb38d78f78d7c7d1579fc0b4c6/docs/opening-with-new-project-system.md#project-type-guids

Actual Behavior

the project type GUID is Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = ...

User Impact

don't know if it impacts someway.
But in my real case .sln i have hundred of projects with {9A19103F-16F7-4668-BE54-9A1E7A4F7556} and now (adding new projects with the just updated visual studio) i get the (bad?) {FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}.

Does it have any impact? I don't know but just in case i'm manually "adjusting" the .sln file...

[julealgon]

This is not specific to .NET9. It apparently happens with any SDK-style project.

I've been fighting this for years now. The easiest way to fix the issue is to remove the project from the solution and re-add it. When it is added, it gets the correct GUID.

I hope the new slnx format is finished soon so that this dumb issue goes away along with the rest of the insanity that is the sln format.

[beppemarazzi]

've been fighting this for years now. The easiest way to fix the issue is to remove the project from the solution and re-add it. When it is added, it gets the correct GUID.

probably it was true for old version of visual studio. With the latest update (17.2.2) also re-adding the project to the sln uses the "bad" GUID...

For me the only workaround is to manually edit the .sln file (I've also created a before build target that issue a compilation warning in case my .sln file contains an old GUID...)

[julealgon]

With the latest update (17.2.2) also re-adding the project to the sln uses the "bad" GUID...

Oh really... I see, they managed to make it worse then 😅

Thanks for clarifying that.

[drewnoakes]

The back-and-forth between project type GUIDs for SDK-style projects should now be resolved, as part of work for SLNX. See #9509.

We now aim to use the same GUID everywhere (the legacy GUID), which should make things simpler to reason about.

[julealgon]

@drewnoakes would you mind sharing a link to where the .slnx work is being done? Ever since I first heard of it, I've been waiting for that to be released so that we can switch immediately to it on our side.

I'd like to track that if possible.

I see this item on the sdk repo. Not sure if it's the main issue though:

• slnx support in the dotnet CLI sdk#40913

[drewnoakes]

I don't know if there's a main issue. The work is being done across several products, from MSBuild to VS to CLI.

[beppemarazzi]

@haileymck @drewnoakes

Sorry for my insistence but i didn't fully understand... it seems to me that we have a "short circuit" between different MS teams (project-system and VS).

AFAIU you are telling that from your point of view now only the legacy GUID is to be used because the new .slnx file format removes the GUID mess.
I opened a similar ticket in VS feedback https://developercommunity.visualstudio.com/t/Projects-are-added-to-solution-with-old-/10800876#T-N10801643 and they reply to me that the solution is to manually edit the .sln file as a workaround.... IMHO It's not a great user experience!!!!

I'm very happy to hear about the new .slnx file format BUT for now since the last VisualStudio (17.2.2) does not still support the .slnx format, we need to know if is really necessary to manually fix the sln files. Does using the legacy GUID instead the SDK style GUID have some consequence?

[julealgon]

@beppemarazzi

AFAIU you are telling that from your point of view now only the legacy GUID is to be used because the new .slnx file format removes the GUID mess. I opened a similar ticket in VS feedback https://developercommunity.visualstudio.com/t/Projects-are-added-to-solution-with-old-/10800876#T-N10801643 and they reply to me that the solution is to manually edit the .sln file as a workaround.... IMHO It's not a great user experience!!!!

Oof.... this is crazy. Encouraging people to touch the .sln file is a recipe for disaster.

I'm very happy to hear about the new .slnx file format BUT for now since the last VisualStudio (17.2.2) does not still support the .slnx format, we need to know if is really necessary to manually fix the sln files. Does using the legacy GUID instead the SDK style GUID have some consequence?

It does but it is in preview. You need to enable it (it is disabled by default). Search for slnx in VS feature search and you should find it:

Once this is enabled, you can take a "legacy" solution and save it as a new slnx solution by clicking on your solution, then going to file -> "Save X.sln As" and picking the slnx format there:

The main problem is that while Visual Studio works fine with it, dotnet CLI does not recognize it at all, forcing you to keep your old sln somewhere for CI/CD purposes for example, which is obviously not usable.

[beppemarazzi]

@julealgon
many thanks for the hints!

I've taken a first look to the new .slnx format and it seems very promising: simple, clear, manually editable and no more unmergeable conflicts!!!!

Unfortunately my real use case actually needs the dotnet CLI command and the full support for .slnf (solution filter) because the whole solution contains more than 200 projects and I'm using few solution filters to "select" different use cases for intermediate building/testing process and/or final deployment...

[drewnoakes]

it seems to me that we have a "short circuit" between different MS teams (project-system and VS)

Project System is part of VS, and we work closely with the Solution Experience team. We're on the same page about this.

I opened a similar ticket in VS feedback https://developercommunity.visualstudio.com/t/Projects-are-added-to-solution-with-old-/10800876#T-N10801643 and they reply to me that the solution is to manually edit the .sln file as a workaround.... IMHO It's not a great user experience!!!!

Apologies for the confusion. I don't believe that's great advice there. The comment was provided in good faith by a support team member but is likely based on outdated info.

Does using the legacy GUID instead the SDK style GUID have some consequence?

Overall, you generally don't need to think about these GUIDs. It was annoying when they would change in the solution file, but that should no longer occur. It doesn't really matter which of the two GUIDs you use in your .sln file, as both will work correctly.

When using the legacy GUID there's a bit of code in VS that scans the XML with a simple heuristic (not using MSBuild, just a SAX-based XML walk) to try and detect SDK-style projects. The only reason you'd ever need to use the newer GUID is if you're doing something really strange in your projects related to SDKs (like specifying them in Directory.Build.* files) such that this fast XML walk cannot detect whether the project is SDK-style or not. I'm pretty sure you don't have to worry about it.

[beppemarazzi]

@drewnoakes
Many thanks for clarification.

EDIT: just found this https://github.com/dotnet/project-system/blob/main/docs/opening-with-new-project-system.md#sdks that exactly respond to my question.
I left here the original just for reference...

About this point:

When using the legacy GUID there's a bit of code in VS that scans the XML with a simple heuristic (not using MSBuild, just a SAX-based XML walk) to try and detect SDK-style projects. The only reason you'd ever need to use the newer GUID is if you're doing something really strange in your projects related to SDKs (like specifying them in Directory.Build.* files) such that this fast XML walk cannot detect whether the project is SDK-style or not. I'm pretty sure you don't have to worry about it.

BINGO: my real case solution contains more than 200 projects and a typical .csproj is one-liner <Project Sdk="Microsoft.NET.Sdk" /> because... yes: I'm using a hierarchy of nested Directory.Build.props and Directory.Build.targets to put all shared things in one single point (i.e. I've only one <TargetFramework>net9.0</TargetFramework> in the root Directory.Build.props).
I don't agree this pattern is

"something really strange"

isn't this the "modern" way to go for a medium-high complex repo? I dislike the same configuration value spreaded across hundreds of files... IMHO it's a mess for maintainability and increases the risk for a false merge conflict..

So i hope the presence of Sdk attribute in my <Project Sdk="Microsoft.NET.Sdk" /> root XML element is enough to trigger the simple heuristic you cited... Just in case is this heuristic code opened in this repo? Could you spot out it?

[drewnoakes]

The pattern <Project Sdk="Microsoft.NET.Sdk" /> is detected as SDK style. The "really strange" pattern I'm referring to would involve putting <Sdk> elements (not attributes) in external files. At that point, there's zero indication in the project file that it's SDK-style. I don't think I've ever seen a case of this.

[julealgon]

When using the legacy GUID there's a bit of code in VS that scans the XML with a simple heuristic (not using MSBuild, just a SAX-based XML walk) to try and detect SDK-style projects. The only reason you'd ever need to use the newer GUID is if you're doing something really strange in your projects related to SDKs (like specifying them in Directory.Build.* files) such that this fast XML walk cannot detect whether the project is SDK-style or not. I'm pretty sure you don't have to worry about it.

@drewnoakes is there any performance penalty related to this additional XML scanning when using the legacy guids that could impact solution/project loading times and/or memory use in Visual Studio?

[drewnoakes]

It's negligible. Never appears on traces.