Open eiriktsarpalis opened 1 month ago
Tagging subscribers to this area: @dotnet/runtime-infrastructure See info in area-owners.md if you want to be subscribed.
it appears this is issue is specific to dotnet/runtime infrastructure which by default uses an OOB compiler
We do this to allows us to get faster end-to-end validation of new C# features and gives us agility with working around bugs. You can see number of instances in the history of the versions file where we took advantage of this - https://github.com/dotnet/runtime/issues/65317 has a bunch of examples.
is issue is specific to dotnet/runtime infrastructure
Does it reproduce when building a regular project with the built-in C# compiler? It would be weird if it did not: one of the ways for an executable to run on .NET Framework on native ARM64 architecture is to target .NET Framework 4.8.1, and the built-in csc.exe
targets 4.7.2. See dotnet/core#7709 for more details about .NET Framework on ARM64.
One other way to enable it would be with a special manifest element, and I have opened dotnet/roslyn#74285 to add it. As a workaround @eiriktsarpalis you can force VBCSCompiler.exe
to run on ARM64 by setting a special registry key.
Does it reproduce when building a regular project with the built-in C# compiler?
Nope, standard projects using the inbox compiler run as arm64 processes.
As a workaround @eiriktsarpalis you can force
VBCSCompiler.exe
to run on ARM64 by setting a special registry key.
Very cool, this solved my problem. For anyone interested you can create the following DWORD values:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\VBCSCompiler.exe\PreferredMachine
andHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\csc.exe\PreferredMachine
set to the hex value of aa64
.
Leaving open until the changes are absorbed in runtime and we revert https://github.com/dotnet/runtime/pull/104812
Even though my VS process is arm64:
Building libraries projects results in an x64 compiler process being used:
Digging deeper, it appears this is issue is specific to dotnet/runtime infrastructure which by default uses an OOB compiler that doesn't support arm64:
I should stress that this has major impact on build performance. For reference, building
System.Text.Json.sln
from the CLI using the arm64 sdk takes 32 seconds whereas building the same solution from VS takes 8 minutes.