`ApplicationManifest` is not respected when building for Windows on Linux
See original GitHub issueDescribe the bug
We want to create a Windows .EXE from our application, in our Linux build chain. We can sucessfully create and run the exectuable on windows, but it comes without the manifest we put in the ApplicationManifest
property in our csproj file.
When building on Windows, the manifest is embedded correctly.
To Reproduce
Create a manifest file to embed, like MyApp.manifest
:
<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<assemblyIdentity type="win32" version="1.0.0.0" name="MyApp" />
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
</requestedPrivileges>
</security>
</trustInfo>
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!--Windows Vista -->
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>
<!--Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<!--Windows 8 -->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
<!--Windows 8.1 -->
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
<!--Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
</application>
</compatibility>
</asmv1:assembly>
In a new console app, add the ApplicationManifest
to a PropertyGroup
:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>net6.0</TargetFramework>
</PropertyGroup>
<PropertyGroup>
<ApplicationManifest>MyApp.manifest</ApplicationManifest>
</PropertyGroup>
....
</Project>
Build it on Windows:
dotnet build -r win-x64 --self-contained -o Build
# Observe that the Exe file in Build has a manifest (a Shield in Windows Explorer to indicate it requires admin)
Build it in Linux (f.ex. the Dotnet 6 SDK docker images):
# Startup a docker container with SDK 6
docker run -it --rm -v $pwd`:/app mcr.microsoft.com/dotnet/sdk:6.0
# Build within Docker
cd /app
dotnet build -r win-x64 --self-contained -o Build
# Back in Windows, observe that the Exe file in Build is lacking a manifest
Exceptions (if any)
N/A
Further technical details
Windows
> dotnet --info
.NET SDK (reflecting any global.json):
Version: 6.0.101
Commit: ef49f6213a
Runtime Environment:
OS Name: Windows
OS Version: 10.0.19043
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\6.0.101\
Host (useful for support):
Version: 6.0.1
Commit: 3a25a7f1cc
.NET SDKs installed:
3.1.416 [C:\Program Files\dotnet\sdk]
5.0.404 [C:\Program Files\dotnet\sdk]
6.0.101 [C:\Program Files\dotnet\sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 3.1.22 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 6.0.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 3.1.22 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.22 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.13 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.1 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
To install additional .NET runtimes or SDKs:
https://aka.ms/dotnet-download
Docker (Linux)
$ dotnet --info
.NET SDK (reflecting any global.json):
Version: 6.0.101
Commit: ef49f6213a
Runtime Environment:
OS Name: debian
OS Version: 11
OS Platform: Linux
RID: debian.11-x64
Base Path: /usr/share/dotnet/sdk/6.0.101/
Host (useful for support):
Version: 6.0.1
Commit: 3a25a7f1cc
.NET SDKs installed:
6.0.101 [/usr/share/dotnet/sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.1 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.1 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
To install additional .NET runtimes or SDKs:
https://aka.ms/dotnet-download
Issue Analytics
- State:
- Created 2 years ago
- Reactions:1
- Comments:12 (6 by maintainers)
Top Results From Across the Web
Deploying a .Net Core application to Linux Service Fabric ...
It runs just fine on a local windows SF Cluster. It consists of a single stateless service with no web component. I'm now...
Read more >Failed to run Service Fabric Container(Windows) on ...
Deployed Service Fabric Container application on local Service Fabric Cluster and Its working fine. On Azure Cloud, created VM with Windows ...
Read more >Working with the Application Manifest
Use mt.exe to interact with the manifest using command-line arguments. If mt.exe is not on the computer, download the Software Development Kit from...
Read more >Building Windows installer on Linux - Editors and IDEs
I've finally found a reasonably good way to build installable Windows executables cross-platform, from Linux.
Read more >AAPT2 | Android Studio
AAPT2 (Android Asset Packaging Tool) is a build tool that Android Studio and Android Gradle Plugin use to compile and package your app's ......
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Just to be clear, there is no real reason why we couldn’t build Windows GUI apps on linux. It’s just the manifest that is broken, even for GUI apps.
Definitely something we would like to implement, it just hasn’t yet raised in priority enough to beat out a variety of other bug fixes and features. We would accept a community PR if someone wants to offer one.