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.'
See original GitHub issueSteps to reproduce
- Create a new SDK project (
dotnet new console
is fine) - Change the csproj so that it targets more than one framework (
<TargetFrameworks>netcoreapp2.0;net461</TargetFrameworks>
, for example) - Create a new solution using the CLI (
dotnet new sln
) - 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]
Issue Analytics
- State:
- Created 5 years ago
- Reactions:1
- Comments:25 (15 by maintainers)
Top Results From Across the Web
dotnet sln command - .NET CLI
The dotnet-sln command provides a convenient option to add, remove, and list projects in a solution file.
Read more >visual studio - `dotnet sln add` wrong project type GUID
The CLI calls into msbuild to get the default project type GUID to use. MSBuild sets the $(DefaultProjectTypeGuid) for C# and VB projects...
Read more >SonarScanner for .NET - SonarQube Docs
The SonarScanner for .NET is the recommended way to launch an analysis for projects built using MSBuild or dotnet.
Read more >Dotnet restore vs nuget restore. Share. In my code repo, there
I have a Visual Studio solution and am trying to build to run on a Linux installation ... I am trying to restore...
Read more >Micro Focus Fortify Static Code Analyzer User Guide
Translating a Single Project from a Visual Studio Solution ... Adding Fortify Static Code Analyzer to your Favorites List.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
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.
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!