Sdk: dotnet sln add returns 'Project 'foo.csproj' has an unknown project type and cannot be added to the solution file. Please contact your SDK provider for support.'

[heemskerkerik]

Steps to reproduce

1. Create a new SDK project (dotnet new console is fine)
2. Change the csproj so that it targets more than one framework (<TargetFrameworks>netcoreapp2.0;net461</TargetFrameworks>, for example)
3. Create a new solution using the CLI (dotnet new sln)
4. Try to add the project from step 1 to the solution created in step 3 (dotnew sln <sln> add <csproj>)

Expected behavior

• Project 'foo.csproj' added to the solution.
• Project is added to the solution

Actual behavior

• Project 'foo.csproj' has an unknown project type and cannot be added to the solution file. Please contact your SDK provider for support.
• Project is not added to the solution

More details

dotnet build on the project just works, so it doesn't look like an issue with targeting packs.

Environment data

dotnet --info output:

.NET Core SDK (reflecting any global.json):
 Version:   2.1.300
 Commit:    adab45bf0c

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17134
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.300\

Host (useful for support):
  Version: 2.1.0
  Commit:  caa7b7e2ba

.NET Core SDKs installed:
  1.1.9 [C:\Program Files\dotnet\sdk]
  2.1.201 [C:\Program Files\dotnet\sdk]
  2.1.300 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

[heemskerkerik]

More information: all of this _does_ work in the 'previous' SDK, at least with 2.1.201.

[livarcocc]

Putting it in 3xx as a potential servicing fix due to a potential regression.

cc @peterhuene

[peterhuene]

I can reproduce. Apparently the default MSBuild props isn't defaulting the project type guids for a multi-targeted project. We may need a fix on their side, as the command is now relying on MSBuild to default the type so that we don't blindly assign everything to be a C# project that's missing one like we were doing previously.

[livarcocc]

Adding @rainersigwald to comment if there were any changes on MSBuild's side that could cause this.

We should also add a test to cover this scenario.

[heemskerkerik]

More information, which might or might not help in pinpointing the issue: it doesn't matter whether you _actually_ specify multiple frameworks. The issue occurs when you use <TargetFrameworks> (plural) instead of <TargetFramework> (singular).

I.e. just changing <TargetFramework>netcoreapp2.1</TargetFramework> to <TargetFrameworks>netcoreapp2.1</TargetFrameworks> will trigger the issue.

[peterhuene]

My guess as to what's happening here is that if TargetFrameworks is used, it alters the expected property evaluation because the Microsoft.CSharp.CurrentVersion.targets and Microsoft.VisualBasic.CurrentVersion.targets (where the DefaultProjectTypeGuid property is set) are not evaluated in the "current" project, but instead by inner cross-targeted builds. This would prevent dotnet sln add from reading the DefaultProjectTypeGuid property correctly.

This could potentially be fixed by having Microsoft.CSharp.CrossTargeting.targets and Microsoft.VisualBasic.CrossTargeting.targets also set DefaultProjectTypeGuid so that anyone doing evaluation of a project file with TargetFrameworks set can evaluate the DefaultProjectTypeGuid property too.

We need to determine if this also impacts F# projects as they also set DefaultProjectTypeGuid in their SDK.

Additionally, dotnet sln add could use a simple file-extension heuristic as a final fallback if the project type guid could not be determined. An easy fix on our side, but I'd also like to take the above suggested MSBuild fix (if that is indeed the issue).

A workaround for 2.1.300 is to comment-out TargetFrameworks in the project file before running dotnet sln add and then uncommenting it after the command runs. Not at all ideal, but it should work.

[heemskerkerik]

A workaround for 2.1.300 is to comment-out TargetFrameworks in the project file before running dotnet sln add and then uncommenting it after the command runs. Not at all ideal, but it should work.

That would work, but I'm using it from a build script to create a giant solution containing many projects. It improves the build times enormously. In theory I could automatically comment out <TargetFrameworks> from the script, but I don't think I want to go there. 😄

[rainersigwald]

I think @peterhuene has nailed the cause here, but I don't understand what's changed. Core MSBuild is unaware of DefaultProjectTypeGuids. Did the SDK move that around?

@heemskerkerik Do you actually need to create a solution? It might be easier to create an MSBuild project that points to all of the projects you want to build at once, rather than add them to a solution.

[peterhuene]

Sorry, had a typo in my comment. It is DefaultProjectTypeGuid and not DefaultProjectTypeGuids.

I think what happened is that @dsplaisted added the property with https://github.com/Microsoft/msbuild/commit/fa7be3599a6386c2d8002050988dc48ad6bd0868, but it wasn't added to the CrossTargeting targets as well. Thus, when you have a cross-targeted project like we have here, the property is never set for an evaluation of the root project file because these targets are only evaluated from within "inner" builds.

This wasn't a problem before I made a change to fix dotnet sln add that prevented it from always using C# as the default project type. It now expects to see a DefaultProjectTypeGuid set as a fallback. However, this would have manifested as a different problem if the project in question were VB/F# and I never made that change: dotnet sln add would have added it as a C# project and VS would use the wrong project system when opening the solution file.

[rainersigwald]

Ah! Yes, that makes sense.

[dsplaisted]

So what's the fix? Are there language-specific cross-targeting targets we should also be setting this property in?

[peterhuene]

Microsoft.CSharp.CrossTargeting.targets and Microsoft.VisualBasic.CrossTargeting.targets I assume.

[peterhuene]

If we're servicing in 2.1.3xx, we could add a "best guess" heuristic fallback on project file extension in the CLI, but this should also be addressed in the common targets.

[andscho-msft]

Seems like I can just add this to my C# projects to work around this for now?

<DefaultProjectTypeGuid>FAE04EC0-301F-11D3-BF4B-00C04F79EFBC</DefaultProjectTypeGuid>

[peterhuene]

It's probably preferable to use <ProjectTypeGuids>{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids> in the project file since we're expecting DefaultProjectTypeGuid to come from the SDK or core targets, whereas ProjectTypeGuids is typically set in the project file itself. That should workaround the issue for now.

Once this is fixed properly, you should be able to remove the workaround.

[heemskerkerik]

@peterhuene Can confirm that adding <DefaultProjectTypeGuid>FAE04EC0-301F-11D3-BF4B-00C04F79EFBC</DefaultProjectTypeGuid> works in 2.1.300.

[JeffN825]

...Is 2.1.300 supposed to be considered an official release?

[peterhuene]

2.1.301 is the current latest version of the .NET Core SDK that targets .NET Core 2.1: https://www.microsoft.com/net/download

But, yes, 2.1.300 was an official release; the first .NET Core SDK release to support .NET Core 2.1.

[TomaszSynak]

I'm also facing the same issue when trying to add *.sfproj to existing sln. Is it supported at the moment, or shall I expect support in future releases ?

[vivmishra]

Approved for 2.1.4XX

[peterhuene]

@TomaszSynak as far as I am aware, Service Fabric projects are normal C# projects using the .NET Core SDK. Unless the project is multi-targeting (the bug outlined in this issue), I'd expect it to add to the solution correctly for 2.1.3xx.

Would it be possible to share with me a simple repro of your problem (preferably a minimal project file that reproduces the problem)? Thanks.

[peterhuene]

Thanks @heemskerkerik for first reporting this issue. A fix has been made to the 2.1.4xx branch and should ship in the upcoming 2.1.400 version of the .NET Core SDK. As such, I'm closing this issue as fixed. Please re-open if you have any questions or concerns. Thanks!

[TomaszSynak]

@peterhuene sorry for late reply. The thing is that in *.sln file, regular *.csproj is identify by GUID FAE04EC0-301F-11D3-BF4B-00C04F79EFBC, while *.sfproj by other GUID A07B5EB6-E848-4116-A8D0-A826331D98C6 and thus is not supported by dotnet sln command :(

I can provide steps to recreate the issue if still needed ? :)

[peterhuene]

Hi @TomaszSynak. That would be super helpful, as I'm unfamiliar with service fabric projects. The fix I've described here to close this particular issue would not resolve yours, I'm afraid. Would it be alright if you opened up another issue that is specific to service fabric projects with the appropriate repro steps for me to investigate? I appreciate your help!