NETSDK1100 blocks building on Linux

[AArnott]

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?

[livarcocc]

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.

[AArnott]

I suppose I could split the project. But I'd sorely miss the virtues that multi-targeting projects brought by converging all those project-per-TFM that we used to see everywhere.

[AArnott]

Ah, but that only really solves the test project problem. I have exactly the same problem in the product project as well. And that project packs all the TFMs together. So splitting that project would require a great deal of effort to write a custom pack step since no one project could self-pack any more. :(

[AArnott]

I'm hitting this again, with another project. I'd very much like to support WPF on .NET Core 3.0 in microsoft/vs-threading#548 but cannot do it because simply referencing WindowsBase in my .NET Core 3.0 target seems to only be doable by setting UseWPF to true in my project file and to set the SDK to Microsoft.NET.Sdk.WindowsDesktop which breaks the build of my library on non-Windows platforms. This is unacceptable as this library targets all platforms and multiple frameworks and we need to be able to build and test on Linux.

How can I get a WindowsBase reference assembly for the .NET Core 3.0 target of the project?

[AArnott]

@livarcocc Your workaround doesn't work either. Even if we have multiple projects, the very fact that we ever used UseWPF=true in the project adds this to my nuspec file:

    <frameworkReferences>
      <group targetFramework=".NETCoreApp3.0">
        <frameworkReference name="Microsoft.WindowsDesktop.App" />
      </group>
    </frameworkReferences>

This kills my project for all downstream consumers of my package that want to build on mac/linux while targeting .NET Core 3.0. They fail with this error:

/home/andrew/.dotnet/sdk/3.0.100/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(263,5): error NETSDK1073: The FrameworkReference 'Microsoft.WindowsDesktop.App' was not recognized

This makes no sense to the downstream consumer because they don't have that FrameworkReference in their project nor do they have any interest in targeting Windows Desktop.
Please! Just give us a ref assembly package we can compile against so that Linux can build (and even run) against, even if they never use that assembly at runtime.

[livarcocc]

I don't think we have changed our position on this. Our concern is folks who do more than just reference assemblies running their builds on linux when their projects depend on windows tools. The chances of success go down drastically and can lead to a very confusing experience.

@nguerrera and @dsplaisted can you think of an alternative here?

[dsplaisted]

I think we went back and forth a bit on this during development. We ended up disabling referencing WindowsDesktop on non-Windows because we didn't want to ship the WindowsDesktop targeting pack together with the SDK on Mac and Linux, but if it was still supported it would have always been downloaded whether it was needed or not, because at the time we're restoring we don't know if it will be needed based on a transitive reference.

I think when we made the decision our intention was to monitor feedback and try to enable the scenario of referencing WindowsDesktop on Mac/Linux in the future if necessary. This seems like an indication that it may be necessary.

[AArnott]

Thanks, @dsplaisted. It sure would make it easier.

At the moment my plan is to remove .NET Core 3.0 WPF/WinForms support from my Xunit.StaFact package because essentially what I have is a regression in my package now. The only way forward (unless we get ref assemblies available off-Windows) will be to create a new Xunit.StaFact.NetCore3.DesktopWindows package so that only those who explicitly want it (and can take the Windows-only restriction) can choose to install it. But that'll be a pain for me and all consumers.

[AArnott]

The xunit workaround is ugly, but at least technically feasible.

For the vs-threading library, it forces us into either of these unfortunate choices:

1. Omit all support for WPF specific behaviors in the netcoreapp3.0 target of the library. This means that net472 of the library is still a proper superset of netcoreapp3.0, but only in the WPF types. WPF users on netcoreapp3.0 are simply out of luck when it comes to what vs-threading can offer.
2. Allow vs-threading's netcoreapp3.0 target to depend on Microsoft.WindowsDesktop.App to offer WPF types, but at the cost of blocking all netcoreapp3.0+ users on mac+linux from using our library. Since these customers already can use the library today, which would be a regression that would force them to use older versions of the library that didn't support WPF on netcoreapp3.0.

Both of these are ugly choices, but the second option is more ugly. So we simply will cut WPF support on netcoreapp3.0 till such time as the .NET Core SDK allows referencing WPF assemblies/packages without breaking linux/mac consumption.

[AArnott]

Given the lack of response to this, I'm going to go ahead and remove .NET Core WPF/WinForms support from Xunit.StaFact (and try to create a separate package to support it, if feasible). (CC: @RussKie)

I'll also plan on never fully supporting WPF on .NET Core in the vs-threading library.

And again, this is because there's no way to support WPF/WinForms on .NET Core 3.0 without dropping support for .NET Core 3.0 on non-Windows OS's. I'm picking the lesser of two evils here. But it's awfully painful to not have what seems like a simple fix to this. I hope it comes one day.