Azure / Azure/azure-sdk-for-rust

Add Windows ARM64 MSVC DLL publication

Open
#5,235 1 comment 1 reaction 0 assignees View on GitHub
Client Cosmos EngSys
Dominant language
Rust
Stars
884
Forks
365
Avg merge
2d 19h
Merged PRs (30d)
112

Description

### Feature Summary

Build, validate, sign, and publish the Cosmos native driver as an `aarch64-pc-windows-msvc` DLL for consumption by the Go V2 SDK without cgo.

### Feature Description

Rust supports Windows ARM64 through `aarch64-pc-windows-msvc`, while Go/cgo does not provide a reliable production path for statically linking the resulting MSVC library. A completed proof of concept showed that a native `windows/arm64` Go process with `CGO_ENABLED=0` can load the Rust MSVC DLL through `golang.org/x/sys/windows`, resolve exports, and exercise runtime, completion-queue, cleanup, negative, and asynchronous transport-error paths without MinGW, an import library, purego, custom assembly, or cgo.

Implement the Rust and publication side of that approach:

- Add a production `aarch64-pc-windows-msvc` build configuration using Microsoft-supported build infrastructure and the required release toolchain.
- Produce `azurecosmosdriver.dll`, its generated C header, PDB, checksums, SBOM, provenance, ABI notes, and version metadata.
- Add pointer-oriented C ABI alternatives for the remaining struct-by-value signatures so Go does not depend on unverified Windows ARM64 aggregate-return or aggregate-argument behavior:
- `cosmos_runtime_options_default()`
- `cosmos_driver_options_config_default()`
- `cosmos_operation_options_default()`
- `cosmos_bytes_free(cosmos_bytes_t)`
- Ensure synchronous and asynchronous exports consistently contain Rust panics at the ABI boundary.
- Authenticode-sign the DLL through the approved Microsoft release process and retain PDB-assisted diagnostics.
- Publish the DLL and evidence into the Windows ARM64 downstream module with an explicit ABI and native-driver version contract.
- Validate lifecycle, completion queue, asynchronous operations, cancellation, multiple producers, unload behavior, and resource cleanup on physical Windows ARM64 hardware.
- Run Application Verifier or equivalent diagnostics and document deployment ACL, servicing, and compatibility requirements.

Definition of done:

- The pipeline reproducibly builds and signs an ARM64 MSVC DLL from a pinned source and toolchain.
- The exported ABI avoids unsupported struct-by-value calls for the Go consumer.
- Published metadata lets consumers verify architecture, version compatibility, integrity, provenance, and signature.
- Credentialed end-to-end tests pass on Windows ARM64 hardware.
- The artifact contract required by the paired Go issue is documented and versioned.

### Use Case

Cosmos Go V2 should support Windows ARM64 without requiring Rust, MSVC, MinGW, or cgo on customer machines.

### Alternatives

Exclude Windows ARM64, or continue investigating static linkage between MSVC Rust and LLVM-MinGW-oriented cgo. The DLL approach has stronger proof-of-concept evidence and avoids CRT, unwind metadata, and dependent-library risks at the static-link boundary.

### Additional Context

Follow-up to #4989, which captured the earlier toolchain investigation. Related work: #4967, #4968, #4969, and #4990. The paired Go issue tracks loading, packaging, compatibility checks, and SDK integration.

Contributor guide

Open the contributing guide

Research direction

Start with the toolchain investigation in #4989 and the paired Go issue, then identify the existing Rust build and publication entry points. Define the ARM64 artifact contract around the listed exports and metadata, and validate lifecycle, asynchronous, cancellation, cleanup, signing, and hardware paths on physical Windows ARM64 hardware.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, rust
Domain
build-system, devops, release, testing-qa
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.