VSadov/Satori
1
0
Fork 0
mirror of https://github.com/VSadov/Satori.git synced 2025-06-08 03:27:04 +09:00
Code Activity

Document arm PreferredMachine settings (#104812)

Browse source 
* Document PreferredMachine workaround for x64 compiler toolset

* Update docs/workflow/requirements/windows-requirements.md

Co-authored-by: Jan Kotas <jkotas@microsoft.com>

* Address feedback

* Address feedback

* simplify

---------

Co-authored-by: Jan Kotas <jkotas@microsoft.com>
This commit is contained in:
Eirik Tsarpalis 2024-07-12 19:13:50 +01:00 • committed by GitHub
parent 062bc0d3f2
commit 42b2fc819b
Signed by: github
GPG key ID: B5690EEEBB952194
1 changed files with 30 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

30
docs/workflow/requirements/windows-requirements.md
View file

@ -108,3 +108,33 @@ You can also temporarily add a directory to the PATH environment variable with t
You can make your change to the PATH variable persistent by going to _Control Panel -> System And Security -> System -> Advanced system settings -> Environment Variables_, and select the `Path` variable under `System Variables` (if you want to change it for all users) or `User Variables` (if you only want to change it for the current user).
Simply edit the PATH variable's value and add the directory (with a semicolon separator).
### Windows on Arm64
The Windows on Arm64 development experience has improved substantially over the last few years, however there are still a few steps you should take to improve performance when developing dotnet/runtime on an ARM device.
During preview releases, the repo sources its compilers from the [Microsoft.NET.Compilers.Toolset](https://www.nuget.org/packages/Microsoft.Net.Compilers.Toolset/) package whose bits aren't configured for the ARM64 build of .NET framework. This can result in [suboptimal performance](https://github.com/dotnet/runtime/issues/104548) when working on libraries in Visual Studio. The issue can be worked around by [configuring the registry](https://github.com/dotnet/runtime/issues/104548#issuecomment-2214581797) to run the compiler as Arm64 processes. The proper fix that will make this workaround unnecessary is being worked on in [this PR](https://github.com/dotnet/roslyn/pull/74285).
Using an Administrator Powershell prompt run the script:
```powershell
function SetPreferredMachineToArm64($imageName)
{
$RegistryPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\${imageName}"
$Name = "PreferredMachine"
$Value = [convert]::ToInt32("aa64", 16)
# Create the key if it does not exist
If (-NOT (Test-Path $RegistryPath)) {
New-Item -Path $RegistryPath -Force | Out-Null
}
# Now set the value
New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
}
SetPreferredMachineToArm64('csc.exe')
SetPreferredMachineToArm64('VBCSCompiler.exe')
```
Then restart any open Visual Studio applications.