sdk: NETSDK1100 blocks building on Linux

I have a test project which multi-targets between net472;netcoreapp2.1;netcoreapp3.0. Only when targeting net472 or netcoreapp3.0 does it reference or use any WPF/WinForms types. Nevertheless, I have to set the SDK attribute to Microsoft.NET.Sdk.WindowsDesktop for this to work with netcoreapp3.0 at all, AFAIK.

This blocks the test project from building the netcoreapp2.1 target on linux, which blocks me testing my library on Linux.

How should I proceed?

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 23
Comments: 33 (16 by maintainers)

Commits related to this issue

Downgrade xunit.stafact package Works around https://github.com/dotnet/sdk/issues/3592 as described in https://github.com/AArnott/Xunit.StaFact/issues/35 — committed to AArnott/vs-threading by AArnott 5 years ago
Update dependencies from https://github.com/dotnet/sdk build 20191115.1 (#3592) - Microsoft.NET.Sdk - 3.1.100-rtm.19565.1 — committed to dsplaisted/sdk by dotnet-maestro[bot] 5 years ago
Use WindowsDesktop SDK to bring Windows Forms and WPF into project. This allow play with .NET Core support for tutorials. These tutorials still can be built only on Windows. See https://github.com/do... — committed to kant2002/infer by kant2002 4 years ago
https://github.com/dotnet/sdk/issues/3592#issuecomment-571346342 — committed to dvolm359-uwsp/my-first-c-sharp-project by daxxog 2 years ago

Most upvoted comments

I ran into this myself with the 3.1 SDK. My workaround was to add this to my csproj file. This is a workaround, of course, so your mileage may vary.

<ItemGroup>
  <KnownFrameworkReference Update="Microsoft.WindowsDesktop.App" IsWindowsOnly="false" />
  <KnownFrameworkReference Update="Microsoft.WindowsDesktop.App.WPF" IsWindowsOnly="false" />
  <KnownFrameworkReference Update="Microsoft.WindowsDesktop.App.WindowsForms" IsWindowsOnly="false" />
</ItemGroup>

+20

natemcmaster on Jan 6, 2020

so we don’t want to bloat the SDK for them by including the support by default.

Why must this additional support be built into the SDK at all? Why not have it be a nuget package that can be referenced by UI projects, that includes the SDK tools necessary to build such projects?

+18

AArnott on Oct 22, 2020

We would like to enable this but it’s certainly not going to be in .NET 5. Part of the issue is that we think most people developing on Mac / Linux will not want to build Windows UI projects, so we don’t want to bloat the SDK for them by including the support by default. For .NET 6, we will be adding more support for .NET SDK optional workloads, which should eventually provide us a way of having the Windows UI support as an optional component that’s not installed by default.

dsplaisted on Oct 22, 2020

I really wish this was higher prioritized. Please allow us to build on Linux when targeting Windows. Take this case: https://github.com/actions/virtual-environments/issues/3577 Basic workflow, that tests all OS and with and without cache of nuget packages: https://github.com/jetersen/dotnet.restore.slow.github.action/blob/main/.github/workflows/ci.yml

slow IO on windows build agents

jetersen on Dec 28, 2021

In more complex cases it might include WPF/WinForms references.

Last I tried (which was a while ago) the .NET SDK was engineered to block WPF/WinForms references unless on Windows. Even though they are just ref assemblies and could compile just fine on another platform. 😦

AArnott on Nov 8, 2021

The original post discusses multi-targeting specifically, but I was wondering what the chances are of being able to build Windows-only applications on Linux in future?

I have a .NET Core WinForms app where only a single UI assembly targets the Microsoft.NET.Sdk.WindowsDesktop framework. I don’t need the UI assembly to run my tests, so there is no need to load or execute it in the build environment. Although I am targeting and developing on Windows, it would be extremely useful to be able to build in e.g. a Docker container.

Would this be as ‘straightforward’ as something like a targeting pack to satisfy type dependencies at build time, or are there other Windows-only tools in play when building an assembly that targets Microsoft.NET.Sdk.WindowsDesktop? Is there any chance of seeing this in 5?

StuYarrow on Oct 21, 2020

Could you split your project? Blocking the usage of that SDK on non-windows platforms is very much by design for us.

We have no considered people multi-targeting with that SDK into older TFMs.

livarcocc on Sep 4, 2019