Skip to content

Conversation

@dotMorten
Copy link
Contributor

Description

I've found that I'm not able to run UWP ARM64 unit test on ARM64 devices.
Looking through the code, there's no indication ARM64 was ever supported, and the OS Architecture detection was getting the wrong values.
This is the beginnings of adding support for executing ARM64 unit tests.
I'm submitting as a draft for now, for feedback, and will also require some more testing at my end.

{
get
{
#if !NETSTANDARD1_4
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't this come from the PlatformEnvironment ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No due to backwards compat reasons this API normally lies about the OS architecture, so this is the way to do it.

@ViktorHofer
Copy link
Member

@dotMorten just because I'm curious, will you finish your work here?

{
// use the new IsWow64Process2 to detect ARM64 as well.
var processHandle = System.Diagnostics.Process.GetCurrentProcess().Handle;
if (IsWow64Process2(processHandle, out ImageFileMachine pProcessMachinem, out ImageFileMachine pNativeMachine))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the m at the end of pProcessMachinem a typo?

Copy link
Contributor Author

@dotMorten dotMorten Jul 4, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I submitted this PR almost a year and a half ago, so honestly I have no clue but probably? 🤷‍♂️. To be honest, I don't even remember submitting this PR.
Feel free to take what I have and work with it, but with such a delay in response and in the mean time I found other means for testing on ARM64, I don't see myself picking this PR up.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will most likely pick this up, when we get ARM64 hardware.

Comment on lines +39 to +40
case ImageFileMachine.IA64:
return Architecture.X64;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IA64 (Itanium) should not be mapped to X64.

Comment on lines +519 to +523
if (architecture == Architecture.X86 && (osArchitecture == Architecture.X64 || osArchitecture == Architecture.ARM64))
{
return;
}
if ((architecture == Architecture.ARM || architecture == Architecture.X86) && osArchitecture == Architecture.ARM64)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The combination architecture == Architecture.X86 && osArchitecture == Architecture.ARM64 is checked twice. Using IsWow64GuestMachineSupported may be more appropriate here.

</data>
<data name="InvalidPlatformType" xml:space="preserve">
<value>Invalid platform type:{0}. Valid platform types are x86, x64 and Arm.</value>
<value>Invalid platform type:{0}. Valid platform types are x86, x64, Arm and Arm64.</value>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

capitalize ARM and ARM64 in messages?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope! This is the correct capitalization

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would use lower case only as in C# compiler usage help. In any case the two lists below should be consistent, and they are not (@nohwnd):

X86,
X64,
ARM,
AnyCPU,
ARM64,
S390x
Valid values are x86, x64 and ARM.</value>

@ViktorHofer
Copy link
Member

@nohwnd I assume you will continue with this work? I guess we still want/need the additional supported architectures?

@nohwnd
Copy link
Member

nohwnd commented Jul 13, 2020

@ViktorHofer yes, but plain tests seem to work just fine on ARM64 already with the custom path to dotnet or the PR that was merged this morning #2479 .

@ViktorHofer
Copy link
Member

Do you know the reason why VSTest isn't AnyCPU by default? Why do we need to pass in the architecture on Core at all?

@nohwnd
Copy link
Member

nohwnd commented Jul 13, 2020

the runner (vstest.console) is anyCPU, but we have architecture specific hosts (testhost), to run the processes at the correct bittness that you select via the settings, to run your tests.

@ViktorHofer
Copy link
Member

I see, that makes sense. Still wondering why the testhost isn't part of the (platform specific) SDK but delivered via the nuget package.

@nohwnd
Copy link
Member

nohwnd commented Jul 13, 2020

@ViktorHofer Because then it can be updated independently, so you don't need to fix your tests every time you install new dotnet sdk. Also you can get updates faster in case you are stuck with a given dotnet sdk.

@Evangelink
Copy link
Member

@dotMorten Thank you for the hard work and sorry it took so long! I will close this PR as we have been merging a couple of PRs providing support for ARM64 in the past months.

Feel free to test it out and let us know if we missed any case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants