`dotnet sln add` wrong project type GUID

Question

When I do dotnet sln add {myProject.csproj} for a .NET Core/Standard project, it adds it as project type (I think) {FAE04EC0-301F-11D3-BF4B-00C04F79EFBC} instead of .NET Core's {9A19103F-16F7-4668-BE54-9A1E7A4F7556}.

Hence, when I open the solution in Visual Studio, it complains and "upgrades" the csproj to a .NET Framework csproj, not a .NET Core one. I can manually edit the sln but it's a chore.

Am I doing something wrong? Are there arguments I'm missing?

Potation

Answer 1

The CLI is actually doing the right thing here, this is a VS/Project System bug.

The CLI calls into msbuild to get the default project type GUID to use. MSBuild sets the $(DefaultProjectTypeGuid) for C# and VB projects to the "classic" one to allow the CLI to add both "classic" and "SDK-style" projects to a solution.

The classic GUID (FAE04EC0…) is then triggering a selection logic that looks if TargetFramework or TargetFrameworks is set in the project to determine if the "new" or "classic" project systems will be used. The idea is that at some point only the new project system will be used and the classic project system may no longer be part of VS in some future update (this is the tone of a lot of comments on GitHub).

According to the logged GitHub issue, the bug is that when the new project system is elected, the solution is updated to the "new" GUID which VS/the solution shouldn't see.

Promoter

ah that might explain why it can't detect it - ive variable-ized things for a central point of configuration – Potation

that seems likely. You could try to fool it with a <TargetFramework>$(TargetFramework)</…> to trigger the project system selector on the classic guid or live with the new guid. Or overwrite DefaultProjectTypeGuid in your central config / Directory.Build.targets to change what the CLI does – Promoter

Answer 2

For anyone coming here trying to understand how and when the legacy .csproj GUID will be opened in the newer SDK-style project system, this document outlines the heuristic used by Visual Studio to determine which project system to use to load the project:

https://github.com/dotnet/project-system/blob/main/docs/opening-with-new-project-system.md

If you use the SDK-style project system's GUID directly, it'll force opening in the newer project system. There's no perceptible performance difference though, so using the older GUID is fine. The GUIDs are listed in that doc too, at the bottom.

Heloise