Unable to get architecture of the current processor

[TonyValenti]

It seems as though the ProcessArchitecture enum does not contain ARM64/32 variants which should be added.

[danmoseley]

It is present?

https://github.com/dotnet/runtime/blob/master/src/libraries/System.Private.CoreLib/src/System/Reflection/ProcessorArchitecture.cs

[TonyValenti]

@danmosemsft I don't believe that is it. How would I get the architecture of the current processor?

This is close:
https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.runtimeinformation.processarchitecture?view=netcore-3.1

But that gives the process architecture of the currently running app, not of the machine.

I need to be able to detect if an x86 app is running on an x64 or arm64 processor. Using the above, running x86 on x64 returns x86 which is not what I need.

[danmoseley]

Ah, I'm not sure whether we attempt to expose that -- generally, the OS tries hard to conceal it from you.

Outside of .NET, I have usually seen people check eg the PROCESSOR_ARCHITEW6432 environment variable (at least that's for detecting WOW64, not sure about on ARM)

[iSazonov]

Is it related with adding osx-arm64 #43313?

[steveharter]

The System.Reflection namespace is not intended for environmental detection. The linked System.Runtime.InteropServices is a better fit.

[AaronRobinsonMSFT]

@danmosemsft and @TonyValenti This is a good question and one that warrants a longer discussion. The RuntimeInformation.ProcessorArchitecture is meant to indicate the processor type the runtime is on top of, not necessarily details about the underlying hardware. Since there is an x86 emulation layer on an ARM64 machine this is stating what it was intended to state - the emulation layer is in play here and confusing things further. I don't think this is something the runtime should try and handle honestly. It becomes an exercise in futility as we must try to constantly peer into how the runtime is being run and honestly the entire point of the runtime is to abstract that away - not possible in all cases but is an ideal.

I also think this is enough of niche case that we should defer this until we get more user feedback. I would have some reservations about creating a new API. For context, APIs that represent this distinction on Windows are GetSystemInfo and GetNativeSystemInfo - the runtime uses GetSystemInfo in the implementation.

[jkotas]

Duplicate of #58463