The AOT containerization story is too difficult

[baronfel]

Right now the AOT stack + this tooling makes it easy to package an AOT'd application for one OS/Arch - the current one. Other OS/arch combinations are blocked by the Native AOT requirement to be on that OS/arch. There are AOT-provisioned .NET SDK container images available starting in .NET 8 that can be used to generate images for:

• linux-x64
• linux-arm64
• linux-musl-x64

but it take a bit of finagling. Here's an example of a command that can be used to generate an image using these SDK images, pushing to github registry:

docker run --rm --pull=always \
          -v $(pwd)/src:/src \
          -v ~/.docker/config.json:/root/.docker/config.json:ro \
          -w /src/aot-sample \
          mcr.microsoft.com/dotnet/nightly/sdk:8.0-jammy-aot \
          sh -c "
            dotnet publish /t:PublishContainer \
              -p ContainerRegistry=ghcr.io \
              -p ContainerRepository=baronfel/aot-sample \
              -p ContainerImageTag=jammy-x64 \
              --use-current-runtime"

The full example can be seen at baronfel/sdk-container-demo.

There's a lot going on here:

• mounting the source code
• setting up docker auth
• choosing the right AOT base image
• building tagging the image with the arch

This is a lot of coordination. We should provide some kind of orchestration here to make it easier to do these AOT steps in these containerized environments to reduce the pain of adopting AOT.

cc @davidfowl @richlander

[baronfel]

I was thinking on this last night, and there may not be a specific dependency on the container targets here - really the logic could look something like:

• user requests Publish with PublishAOT set
• if on matching platform, do AOT publish locally
• if not on matching platform, do publish inside a matching SDK container - mapping in sources, etc to try and reuse existing caches as much as possible
• after this publish, make sure the outputs end up in PublishDir
• continue to SDK containerization targets as normal because PublishDir is the true data dependency here