-
Notifications
You must be signed in to change notification settings - Fork 5.3k
consume MsQuic 2.1 for windows ARM64 builds #73713
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
Conversation
|
Tagging subscribers to this area: @dotnet/ncl Issue DetailsWe don't have Windows ARM pipeline for msquic transport. This change consumes ARM bits published by msquic directly.
|
|
btw |
|
/azp run runtime-extra-platforms |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
I thought you had a PR to dotnet/msquic which would build the DLL for ARM so we could consume it as we do for x86/x64 |
|
@rzikm building on arm is problematic - this is easiest route. Even for Linux we are looking into cross-compilation on our side. |
|
Windows arm64 pipeline was cancelled - https://github.com/dotnet/runtime/runs/7782294163
|
|
It was not meant as permanent change. Sees like we don't have hardware so we will not get any windows arm tests @karelz. |
|
Tested locally on Volterra device: |
#73713 added Windows.11.Arm64.Open runs to check MsQuic functionality there, but currently, there is no HW servicing the queue and the ci job timeouts. This PR temporarily suspends runs on the queue until appropriate HW is deployed to helix.
We don't have Windows ARM pipeline for msquic transport. This change consumes ARM bits published by msquic directly.
(This does not allow us easily consume daily builds & fixes but that should OK for now)