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.

[dsplaisted]

FYI this is on our radar. I think we will try to improve this for .NET 5 (no promises of course).

[natemcmaster]

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>

[StuYarrow]

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?

[weltkante]

I was wondering what the chances are of being able to build Windows-only applications on Linux in future

There are some discussions for this in the individual projects (WinForms and WPF) - there is some interest to have this happen, but I'm not aware of anyone actively working towards it.

Is there any chance of seeing this in 5?

Unlikely since I've not noticed anyone working on it, and .NET 5 is close to release (nothing new going in at this point). Some people claim to have gotten cross compilation on Linux targeting Windows working for some specific scenarios by using workarounds, but I haven't been following these discussions nor have I tried it myself.

[dsplaisted]

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.

[AArnott]

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?

[jetersen]

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>

Sadly this workaround does not work for net5.0-windows 😢 This would help save a lot of GitHub Actions minutes if we could build on ubuntu.

[MichaelVoelkel]

Still seems to be an issue, also on Mac... Any idea how to fix?

[AlexSchuetz]

We are seeing this issue as well. We have an cross-platform application consisting of several binaries/projects. Only one of those project targets net5.0-windows.
We use a dockerized build based on mcr.microsoft.com/dotnet/sdk:5.0 and I really expected the SDK-image to be able to build all net5.0 and netcore-apps.

IMO: saving some MB or even GB of data is not a good arguement to break docker builds. Probably no one will be noticing it if you include it , except of the people, that are trying to do reproducable cross-platform builds, that are going to work then.

I'am developing some xamarin-apps as well and the biggest inconvenience there is that if you want to build a release you have to start compiling the code on different platforms. Please don't go the same route with NET5 and NET6. It will make me regret not to have chosen electron.

I tried switching to mcr.microsoft.com/dotnet/sdk:6.0, but it resulted in the same error:

1.514 /usr/share/dotnet/sdk/6.0.100-preview.3.21202.5/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.FrameworkReferenceResolution.targets(64,5): error NETSDK1100: Windows is required to build Windows desktop applications.

[iMonZ]

I have the same issue on macOS

[bnitt]

same issue on mac visual studio

[imuller]

@iMonZ @bnitt Got it working by opening the solution in Visual Studio for Mac. Then remove the WinUI project. After that i can build the iOS project for example.

[Misiu]

any updates on that?
I want to build my solution in docker and I have one project targeting .net core 3.1 and WinEexe, so my CI fails right now.
Can I swap mcr.microsoft.com/dotnet/core/sdk:3.1 to a different image? If yes, then which one should I pick.

[maxkatz6]

So, net6 was released and it still an issue.
Any net6.0-windows10.0.17763 or similar project will be a dead weight in your solution, if you want to be able to build it on different platforms. Not to mention, Rider can't restore anything in this project, so it basically full of errors.
There is no way to check if there are any compile-time errors (nobody expects to run windows app on mac, but at least to be able to build it).

[maxkatz6]

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

It makes sense, but you don't need to use WinUI to be required to use "net6.0-windows10.0.xxxxx" target.
To simplify the problem, your requirement might be to build console app but use native APIs in different projects (windows specific one, macos specific one...). Without WinUI, only CsWinRT. In more complex cases it might include WPF/WinForms references.

[AArnott]

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. :(

[markbeaton]

We'd dearly love to be able to do this as well.

In our case, our CI/CD environment runs on macOS, and part of it uses a local SonarQube installation to build and analyse the codebase. We have a single .sln for the SonarQube builds, but that obviously fails as soon as a WPF project is added to the solution.

That currently leaves us with two options: either set up a Windows-based build environment just for the WPF app (which then means two sets of SonarQube analysis runs/reports), or remove the WPF app project from the solution (meaning no SonarQube analysis for any WPF-specific code).

[maxkatz6]

Does anybody knows currently working workarounds for .net 5/6? Apart from using separated sln.

[jetersen]

I really wish this was higher prioritized. Please allow us to build on Linux when targeting Windows.
Take this case: actions/runner-images#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

[pr8x]

Ridiculous that this doesn't work.

[wendreof]

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>

This workaround just saved me. Now my application is building properly on GitLab CI.

My setup:

• Docker image: mcr.microsoft.com/dotnet/sdk:6.0
• Application Type: Windows Forms
• .NET: 3.1

Thank u!

[dfederm]

For my scenario at least, the fix was to add this property to the project:

<EnableWindowsTargeting>true</EnableWindowsTargeting>

My scenario being that I'm referencing the latest Microsoft.Identity.Client which has a FrameworkReference to Microsoft.WindowsDesktop.App.WindowsForms, targeting net7.0-windows, and building on Linux.

[marcpopMSFT]

Looks like we never closed this when Daniel added that new property as a workaround.

[emmenlau]

I'm sorry but I do not understand how these workarounds are supposed to work. Can someone please elaborate?

I have a WPF project that I'd like to compile on Linux, mostly as part of the CI to check the build works. I would not mind if the produced executable does not work.

I already set <EnableWindowsTargeting>true</EnableWindowsTargeting> to true. This used to work like a year ago, but sadly I do not remember the .Net version I was using. I think it may have been .Net 6 or .Net 7, but I may be wrong. I stopped testing the project for about a year, and now as of .Net 8.0.110 on Ubuntu 24.04, the build fails with error:

[build]   Determining projects to restore...
[build]   Restored /home/memmenlauer/BDA/Src/BDAImageAcquire/csharp_wpf/BDAImageAcquire.WPF.csproj (in 240 ms).
[build]   1 of 2 projects are up-to-date for restore.
[build] /usr/lib/dotnet/sdk/8.0.110/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(1355,3): error MSB4019: The imported project "/usr/lib/dotnet/sdk/8.0.110/Sdks/Microsoft.NET.Sdk.WindowsDesktop/targets/Microsoft.NET.Sdk.WindowsDesktop.targets" was not found. Confirm that the expression in the Import declaration ";/usr/lib/dotnet/sdk/8.0.110/Sdks/Microsoft.NET.Sdk/targets/../../Microsoft.NET.Sdk.WindowsDesktop/targets/Microsoft.NET.Sdk.WindowsDesktop.targets" is correct, and that the file exists on disk. [/home/memmenlauer/BDA/Src/BDAImageAcquire/csharp_wpf/BDAImageAcquire.WPF.csproj]
[build] 
[build] Build FAILED.
[build] 
[build] /usr/lib/dotnet/sdk/8.0.110/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(1355,3): error MSB4019: The imported project "/usr/lib/dotnet/sdk/8.0.110/Sdks/Microsoft.NET.Sdk.WindowsDesktop/targets/Microsoft.NET.Sdk.WindowsDesktop.targets" was not found. Confirm that the expression in the Import declaration ";/usr/lib/dotnet/sdk/8.0.110/Sdks/Microsoft.NET.Sdk/targets/../../Microsoft.NET.Sdk.WindowsDesktop/targets/Microsoft.NET.Sdk.WindowsDesktop.targets" is correct, and that the file exists on disk. [/home/memmenlauer/BDA/Src/BDAImageAcquire/csharp_wpf/BDAImageAcquire.WPF.csproj]
[build]     0 Warning(s)
[build]     1 Error(s)
[build] 
[build] Time Elapsed 00:00:00.92

Here is my dotnet --info:

.NET SDK:
 Version:           8.0.110
 Commit:            87a66bb3d1
 Workload version:  8.0.100-manifests.9143487c

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  24.04
 OS Platform: Linux
 RID:         ubuntu.24.04-x64
 Base Path:   /usr/lib/dotnet/sdk/8.0.110/

.NET workloads installed:
 Workload version: 8.0.100-manifests.9143487c
There are no installed workloads to display.

Host:
  Version:      8.0.10
  Architecture: x64
  Commit:       81cabf2857

.NET SDKs installed:
  8.0.110 [/usr/lib/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 8.0.10 [/usr/lib/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 8.0.10 [/usr/lib/dotnet/shared/Microsoft.NETCore.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

[allsorts46]

@emmenlau I've also just run into this today, also .net 8 on Ubuntu 24.04.

For me the issue was that I was using the 'new' Ubuntu-packaged release of dotnet instead of the Microsoft release. See this discussion. Seems the Ubuntu packages do not include the full set of workloads required for targeting Windows builds.

The solution was remove all the Ubuntu dotnet packages (apt --purge remove dotnet*) and then install using the Microsoft install script instead (don't forget to add to your path). After that I was able to build my project which targets both net8.0 and net8.0-windows without any problems.

Using the Microsoft packages over the Ubuntu ones may not be appropriate for you for other reasons. There is a post further down in that discussion link which suggests it's possible to manually download and extract the workload files and copy them in to the correct place in your dotnet installation, but that sounds like a maintenance nightmare to me - for me the script was the way to go.

[emmenlau]

For me the issue was that I was using the 'new' Ubuntu-packaged release of dotnet instead of the Microsoft release. See this discussion. Seems the Ubuntu packages do not include the full set of workloads required for targeting Windows builds.

Oh my, this seems to be the solution!!! I've just briefly tested it, and indeed, the Microsoft official upstream packages contain several more SDKs, which are missing in the Ubuntu provided packages. This is quite sad and frustrating, since all Microsoft websites recommend the Ubuntu packages. But at least there is some solution!