EnableWindowsTargeting does not work well for building WinApps in linux

[ali50m]

Hi Team,

I am trying to build and publish my WPF(.net7-windows) through the github action pipeline. After reading this blog, I find EnableWindowsTargeting can be used for build Windows App on a linux machine.

However, after publishing the app in ubuntu-latest runner and run it, I find there is a unwanted console output window after my app is lauching. It does not act like the building artifact from windows machine.

I also tried publish the app on ther linux machines and found the same behavior. The console output window is annoying.

You can also see this issue in this blog.

Please kindly let me know if there is any other properties need to combine with EnableWindowsTargeting for building a WPF app in linux, or it is a bug?

BTW, the windows runner for github action is really slow, and expensive, comparing to ubuntu runner. :(

---

Document Details

⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

• ID: b07d5584-04d1-9972-c2d6-ffaa3cf5512a
• Version Independent ID: 5aa55844-314a-2c33-4cdc-b9e1de62e029
• Content: NETSDK1100: Set the EnableWindowsTargeting property to true - .NET CLI
• Content Source: docs/core/tools/sdk-errors/netsdk1100.md
• Product: dotnet-fundamentals
• Technology: dotnet-cli
• GitHub Login: @tdykstra
• Microsoft Alias: tdykstra

---

Associated WorkItem - 69434

[ali50m]

#30076

[tdykstra]

@marcpopMSFT who can help with this issue?

[abitzer]

I have the same issue on .NET 6.0.
It seems the PE Header of the executable "states:

• "User Interface" : "Windows console" rather than "Windows GUI"
• In addition the file information like e.g. File Version, Company Name, ... are missing

[marcpopMSFT]

Adding @dsplaisted who did that feature. I think the extra window comes from the apptype being winexe though I'm not sure why it would behave differently when built on windows versus linux.

[abitzer]

I think this could be a side effect of: dotnet/runtime#3828

[dsplaisted]

I think this could be a side effect of: dotnet/runtime#3828

That's correct. Currently EnableWindowsTargeting is more meant to allow you to check that your Windows-targeted code compiles correctly, so you can make changes on Mac OS or Linux and not have to worry as much about whether you've broken the Windows build.

For actually producing the app that will be shipped, you still should generally do that from a Windows OS. Fixing dotnet/runtime#3828 would be a good step, but even if we do that there might be other issues that prevent the output from a non-Windows build from being the same as when building on Windows.

[ali50m]

I am not sure whether the original intention of this design is to allow users to compile programs for windows on different platforms. Judging from the problems reported by NETSDK1100, it seems to be so.

I think, if .net team can't make .net Windows program run cross-platform, but at least please make it cross-platform compiling, so that developers can easily use linux CI/CD to build release applications.

[curia-damiano]

The docs at https://learn.microsoft.com/en-us/dotnet/core/project-sdk/msbuild-props#enablewindowstargeting state this:

Set the EnableWindowsTargeting property to true to build Windows apps (for example, Windows Forms or Windows Presentation Foundation apps) on a non-Windows platform. If you don't set this property to true, you'll get build warning NETSDK1100. This error occurs because targeting and runtime packs aren't automatically downloaded on platforms that aren't supported. By setting this property, those packs are downloaded when cross-targeting.

We could correct the docs into "to test the buildability of Windows apps... on a non-Windows platform".
But in the current state, the Windows build should run fine on Linux.

[dsplaisted]

@tdykstra Per the discussion here, it would be good to update the docs for EnableWindowsTargeting to include something like this:

NOTE: This property is currently recommended to allow development on non-Windows platforms. The final application that is released should still be built on Windows. When building on a non-Windows platform, the output may not be the same as when building on Windows. In particular, the executable will not be marked as a Windows application (which means that it will always launch a console window) and won't have an icon embedded.

[alexrp]

Note that this needs to be revisited after:

• Crossplatform ResourceUpdater runtime#89303
• Crossplatform ResourceUpdater sdk#34394