-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Request]: Implement support for native ARM64 enablement in NetFx AnyCPU executables #10060
Comments
The project system in VS will likely expose the new prop as a check box with some of the validation specified above, e.g. enabled only when targeting NetFx AnyCPU. |
The supportedArchitectures documentation https://learn.microsoft.com/en-us/windows/win32/sbscs/application-manifests#supportedarchitectures says
Which seems to mean that the element applies only to .NET and not to .NET Framework. Is it actually the other way around? This text came from MicrosoftDocs/win32#1803. |
It's the other way round - Windows is not involved with activating the runtime for .NET (Core) executables. |
@KalleOlaviNiemitalo thank you for pointing it out. Documentation update: MicrosoftDocs/win32#1855 |
Summary
Windows is adding support for "arm64" as the supported architecture listed in the Win32 executable manifest. AnyCPU executables with such an element in the manifest will run natively on ARM64 Windows. This issue is about having MSBuild support the new thing by adding a new property called
PreferNativeArm64
.Background and Motivation
The behavior on ARM64 Windows so far has been for AnyCPU executables to run emulated, out of the fear that the developer may not have anticipated such an architecture when they built the program. This is similar to the
Prefer32Bit
property, which was added some time ago to keep AnyCPU executables running in 32-bit WoW on x64 Windows.Proposed Feature
A new property called
PreferNativeArm64
is understood by common targets. Notable differences betweenPreferNativeArm64
and the existingPrefer32Bit
prop are:Prefer32Bit
is true by default and the developer has to opt out by setting it to false.PreferNativeArm64
is a false-by-default opt-in switch.Prefer32Bit
translates to a bit in the COR header whilePreferNativeArm64
makes the toolchain add an element to the Win32 manifest embedded in the executable.At high level, if the new property is set to true, MSBuild will generate a manifest file with the following contents:
The contents is combined from two sources. It is the new
<supportedArchitectures>
element merged with the contents of the file nameddefault.win32manifest
in the .NET Framework install folder (commonly C:\Windows\Microsoft.NET\Framework\v4.0.30319). This ensures that the manifest will be the same as what's embedded by the C#/VB compiler by default, other than the new element.If the project already specifies a custom Win32 manifest using the
ApplicationManifest
property, this file is used as a source instead ofdefault.win32manifest
and the<supportedArchitectures>
element is merged into it. That way the manifest will be the same as what's embedded by the C#/VB compiler when it's passed a-win32manifest
, other than the new element.Error conditions:
PreferNativeArm64
is true andPrefer32Bit
is explicitly set to true, a build error is reported. These two options are mutually exclusive.PreferNativeArm64
is true and theNoWin32Manifest
is true, a build error is reported. These two options are mutually exclusive.PreferNativeArm64
is true, a custom manifest is specified usingApplicationManifest
, and the manifest already contains the<supportedArchitectures>
element with something else than "amd64 arm64", a build error is reported.PreferNativeArm64
is true and the project does not target .NET Framework, a build warning is reported. This is similar to how the build already warns aboutPrefer32Bit
when not targeting .NET Framework.PreferNativeArm64
is true and the project targets other platform than AnyCPU, a build warning is reported.Prefer32Bit
does not seem to implement this validation in common targets.Alternative Designs
We could alternatively add a new flag to the C#/VB compiler, pushing the work of injecting the
<supportedArchitectures>
element to the default or user-specified manifest down to the compiler. However, MSBuild is better positioned for this work because it is a single choking point for potentially multiple compilers.The text was updated successfully, but these errors were encountered: