Sdk: Having .net core WPF project in Solution prevents Nuget Restore on Linux / macOS

[GregAlexJames]

By design, you do not want .net core WPF and WinForms projects building on platforms other than windows (as per @livarcocc on https://github.com/dotnet/sdk/issues/3592 ). When you do so it presents the following error:

/usr/local/share/dotnet/sdk/3.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(59,5): error NETSDK1100: Windows is required to build Windows desktop applications

Which is fine. The problem is that if a solution simply contains a .net core WPF project, that solution will no longer be able to complete a "dotnet restore" on the solution, even if you intend to build other projects (eg a dotnet core console application on macOS). This prevents the ability to build other projects within the solution because you can not get the nuget packages. This also breaks the developers experience on the other platforms (with Visual Studio for Mac no longer able to restore packages easily).

Can the way you block WPF builds on linux / macOS be changed so not to break dotnet restore on the solution?

Reproduction Steps:
Be on MacOS
Create a new solution
Inside solution add new wpf core project using "dotnet new wpf"
Inside solution add new .net core console application

With the above steps you can no longer build the console application on macOS due to NETSDK1100 as the solution nuget restore fails.

The only workaround is to (a) use the command line to do a dotnet restore on the console application project itself. This doesnt help if you have multiple other projects though each requiring this to occur (or made more difficult if you have also a Xamarin.Mac project that does not use dotnet core). Another workaround is (b) separate solutions, but this will hinder development if they share common code.

(using dotnet core 3.0.100)

Context: We have multiple common code .net standard projects with multiple front end projects for platforms like Windows, macOS, iOS, Android etc. They all load under the single solution allowing to easily complete refactors / minor code changes on other platforms if you need to do a breaking change in common code, and multiple build configurations for building specific clients.

I am now forced to have two solutions, one for building on linux / macOS, and one for windows. This means that anyone developing on linux / macOS are now more likely to miss required changes for WPF. This has only become an issue since updating from .net framework to .net core.

[StefanStolz]

We have exactly the same issue.

Currently we restore project by project in a script.

[livarcocc]

My concern with a change like this is that people my silent assume that because they build their solution in Linux with a WPF project that they take it to mean that it worked and is supported. And then they will get confused when there are not binaries for those projects.

Similarly, if you have P2P dependencies to WPF/WinForms projects, it will be confusing and hard to understand why it is not building if we have this implicit rules.

I prefer the simplicity of simply failing and proposed that you build a separate solution for your non-windows build. I recognize that is not ideal, but I believe it will end up being simpler and less confusing.

[GregAlexJames]

@livarcocc I have no issue with the WPF core build failing on linux. The problem here is that you make all projects in a solution fail (including those specific to the linux / macOS world like a Xamarin.Mac client) because nuget restore / dotnet restore fails on the solution. Having dotnet build fail on the solution for the WPF project would be perfectly fine.

The way you stop the WPF build should not stop a nuget restore, but break when the project itself is built.

Everything about the simplicity I agree with you. The problem is not with the idea, but the current implementation as it is a touch overreaching (affecting dotnet restore instead of just dotnet build) , and affects other projects in the same solution.

[sharpSteff]

It would be great to have an optional -c "Configuration" parameter like in dotnet build, to be at least be able to filter out the WPF-projects via the solution-configuration

[PatrickRainer]

Same Problem, have a Solution with different Libraries, a WPF project and a Xamarin Project. When I want to build xamarin.iOS the nuget packages cannot be restored, due it's not a windows agent.

[bopin2020]

Same Problem, have a Solution with different Libraries, a WPF project and a Xamarin Project. When I want to build xamarin.iOS the nuget packages cannot be restored, due it's not a windows agent.

Me too. I used .NET5 to create a WPF project on the linux system, but "error NETSDK1100" devil become more hateful. Here: https://github.com/dotnet/core/issues/5545. BTW, I hate red color :)

[brantburnett]

My use case I haven't even found a workaround for, yet. I have an application that can be built command-line only and run in Docker or when built for Windows shows a WinForms UI. Trying to upgrade to .NET 5, and use <TargetFrameworks>net5.0;net5.0-windows<TargetFrameworks>, all the WinForms stuff is excluded for the plain net5.0 target. However, I can't build the Docker image version, even though I'm only building the net5.0 target, because I can't run dotnet restore. Since it's one project, not separate projects in a solution, I can't even script it as separate restores.

I agree, blocking this in dotnet restore is too early, it should only block on build. Or, at least, a way to run a targetted restore for a specific framework is required. If I find a workaround I'll update.

[pitchalt]

@livarcocc Please could you explain why it is not possible to build an application for windowsdesktop on Mac. Actually, I don't need to run it on a Mac. I would like to use CI/DI to build a solution on Linux. The SDK has a compiler, libraries have a single format, what prevents you from building windowsdesktop applications on platforms other than Windows?