How do x64 and Arm64 CPU architectures differ, and what does a .NET team need to check before running services on Arm64 servers or developing on Apple Silicon?

1. Memory ordering, the subtle difference

Thread A (writer)              Thread B (reader)
data = 42;                     if (ready)
ready = true;                      Console.WriteLine(data);

• On x64, stores become visible in program order, so B effectively never sees ready == true with stale data, as long as the JIT doesn't reorder (and it may).
• On Arm64, the hardware itself may make ready visible before data, so B can print 0.
• Correct code uses Volatile.Write(ref ready, true) and Volatile.Read(ref ready), a lock, Interlocked, or higher-level types (Lazy<T>, ConcurrentDictionary, Channel<T>). The .NET memory model documents the guarantees; anything beyond them is a race on every platform, but Arm64 exposes it more often.

2. Native assets in NuGet packages

MyPackage.nupkg
|-- lib/net8.0/MyPackage.dll                   managed, works everywhere
`-- runtimes/
    |-- win-x64/native/mylib.dll
    |-- linux-x64/native/libmylib.so
    `-- linux-arm64/native/libmylib.so         <- must exist for Arm64

Check with: unpack the .nupkg (it's a ZIP) or look at the package's "Frameworks" and documentation; then run the app's test suite on an Arm64 agent.

3. Building multi-arch container images

FROM --platform=$BUILDPLATFORM mcr.microsoft.com/dotnet/sdk:10.0 AS build
ARG TARGETARCH
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -a $TARGETARCH -o /app

FROM mcr.microsoft.com/dotnet/aspnet:10.0
WORKDIR /app
COPY --from=build /app .
ENTRYPOINT ["dotnet", "Api.dll"]

docker buildx build --platform linux/amd64,linux/arm64 -t myregistry/api:1.2.3 --push .

The build stage runs natively on the build machine and cross-compiles with -a $TARGETARCH; only the final stage is per-architecture. Alternatively, dotnet publish /t:PublishContainer with ContainerRuntimeIdentifiers builds images without a Dockerfile.

4. SIMD portability

Vector256<T> on Arm64 is emulated with two 128-bit operations (Vector256.IsHardwareAccelerated is false), so Vector128<T> is the portable sweet spot.

5. Migration checklist

1. Inventory native dependencies and tools (APM agents, profilers).
2. Add an Arm64 CI leg that runs the full test suite.
3. Publish multi-arch images.
4. Run load tests on the target VM size and compare latency, throughput and cost.
5. Roll out gradually (a canary node pool), with an easy way back to x64.
6. Review lock-free or hand-rolled concurrency code for memory ordering assumptions.

6. Try it yourself

1. Print RuntimeInformation.ProcessArchitecture and OSArchitecture on your machine and inside an arm64 container.
2. Build a multi-arch image with the Dockerfile above and inspect the manifest with docker buildx imagetools inspect.
3. Write a small method using Vector128 and look at the disassembly on x64 and on Arm64 (an Apple Silicon Mac or an Arm64 VM) with DOTNET_JitDisasm.

namespace ArchitectureAware;

using System.Runtime.InteropServices;
using System.Runtime.Intrinsics;

public static class Program
{
    public static void Main()
    {
        Console.WriteLine($"Process architecture: {RuntimeInformation.ProcessArchitecture}");
        Console.WriteLine($"OS architecture:      {RuntimeInformation.OSArchitecture}");
        Console.WriteLine($"Runtime identifier:   {RuntimeInformation.RuntimeIdentifier}");
        Console.WriteLine($"Vector128 hardware:   {Vector128.IsHardwareAccelerated}");
        Console.WriteLine($"Vector256 hardware:   {Vector256.IsHardwareAccelerated}");
    }
}

// Correct cross-thread publication on every architecture
public sealed class ConfigHolder
{
    private Config? _current;

    public void Publish(Config config) => Volatile.Write(ref _current, config);

    public Config? Current => Volatile.Read(ref _current);
}

public sealed record Config(string Endpoint, int TimeoutSeconds);

# Publish for Arm64 Linux, self-contained, from any machine
dotnet publish -c Release -r linux-arm64 --self-contained

# Or build a container image for both architectures with the SDK (no Dockerfile)
dotnet publish -c Release /t:PublishContainer -p:ContainerRuntimeIdentifiers="linux-x64;linux-arm64"