Eine .NET-11-Preview gefahrlos im Container testen
- Matt
Ich wollte das neue runtime-native async aus .NET 11 ausprobieren, ohne dass mir die Preview-SDK die lokale Installation verhagelt. Preview-SDKs landen global neben allen anderen Versionen in dotnet --list-sdks, und ohne global.json wird die neueste installierte Version stillschweigend zur bevorzugten - für jedes Projekt im Ordner, nicht nur für das eine, das ich testen wollte.
Das Nightly-Image
Preview- und Nightly-Builds liegen nicht unter mcr.microsoft.com/dotnet/sdk, sondern in einem eigenen Repository: mcr.microsoft.com/dotnet/nightly/sdk. Ein Container ist vom Host isoliert, verschwindet nach dem Beenden wieder und hinterlässt keine SDK-Leiche irgendwo im Dateisystem:
docker run --rm -it -v "${PWD}:/src" -w /src mcr.microsoft.com/dotnet/nightly/sdk:11.0-preview bash
Der Tag 11.0-preview zeigt immer auf die aktuellste Preview, derzeit Preview 6. Wer eine bestimmte Version nachbauen will, etwa weil ein Kollege denselben Stand testen soll, pinnt stattdessen 11.0.100-preview.6. Beide Tags sind Multi-Arch-Manifeste, Docker zieht automatisch die passende Variante für amd64 oder arm64.
Im Container zeigt dotnet --version sofort die Preview-Version - ganz ohne global.json, weil schlicht keine andere SDK-Version im Weg steht.
Restore und Cache
Ohne gemounteten NuGet-Cache lädt jeder Containerstart sämtliche Pakete neu herunter, das kostet bei jedem docker run wieder eine Minute Wartezeit. Ein zusätzliches Volume hält den Cache zwischen den Läufen fest:
-v "${HOME}/.nuget/packages:/root/.nuget/packages"
Erst danach fühlt sich das Hin- und Herspringen zwischen der installierten .NET-10-SDK und der Preview im Container nicht mehr wie ein Umweg an.
Wo es hakt
Für das Nightly-Image gibt es keine Supportzusage, und zwischen zwei Previews kann brechen, was in der vorherigen noch lief. Die Liste der Breaking Changes in .NET 11 wächst mit jeder Preview weiter. Dazu kommt, dass manche NuGet-Pakete, vor allem Analyzer und Source Generatoren, gegen die neue SDK-Version noch nicht getestet sind und den Restore mit wenig hilfreichen Fehlermeldungen quittieren. Für einen kurzen Blick auf ein einzelnes Feature reicht der Container trotzdem aus - für eine echte Migration warte ich auf die erste Release Candidate.