11

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?

halfer
  • 19,824
  • 17
  • 99
  • 186
Daniel A. White
  • 187,200
  • 47
  • 362
  • 445

1 Answers1

10

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.

Martin Ullrich
  • 94,744
  • 25
  • 252
  • 217
  • ah that might explain why it can't detect it - ive variable-ized things for a central point of configuration – Daniel A. White Nov 15 '17 at 19:07
  • 1
    that seems likely. You could try to fool it with a `$(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 – Martin Ullrich Nov 15 '17 at 19:11