Quasi-Build-Container für .NET Framework #1

New issue

Open

opened 2026-09-07 13:39:25 +00:00 by Christian · 0 comments

Christian commented

2026-09-07 13:39:25 +00:00

Owner

Ich hab da eine noch unausgegorene Idee, plus die Learnings aus einer ersten Recherche.

Idee

Die VM als Buildserver für .NET-Solutions, die noch auf .NET Framework und WPF laufen.
Ablauf: Repo per scp rein, per SSH einloggen, ein MSBuild-Aufruf, Ergebnis zurückgeben, fertig.
Bedingung: kein Internet für den Container. Windows macht dann bloß Blödsinn wie 80% der verfügbaren Ressourcen in Updates stecken, wo der einzige Auftrag "bau das Projekt" ist.

Learnings

reicht vllt. nur die .NET-Framework SDK? => leider nein
VS 2022 oder neuer? VS 2022 aus Gewohnheit.

Learnings, Zusammenfassung von CLaude, runtergebrochen

Was das .NET-Framework-SDK nicht kann

Das Developer Pack liefert Reference Assemblies. Kein MSBuild, kein Compiler, keine WPF-Targets.
dotnet build versteht klassische .csproj nicht. Nur MSBuild.exe.
Was fehlt, liefern die VS Build Tools, Workload ManagedDesktopBuildTools, dazu je ein Targeting Pack pro vorkommender Framework-Version.
Die Build Tools sind lizenzrechtlich für Buildserver gedacht. VS Community ist es nicht.

Offline-Installation

vs_BuildTools.exe --layout lädt ein vollständiges Offline-Paket herunter, aus dem danach ohne Netz installiert wird.
--layout ist eine Windows-EXE. Läuft nicht auf Linux, Wine ist für den VS-Installer aussichtslos. Es braucht also einmalig eine Windows-Kiste mit Netz.
--lang weglassen zieht alle Sprachpakete und bläht das Layout um ein Vielfaches auf.
--noWeb bei der Installation weglassen schickt den Installer trotz fertigem Layout ins Netz, wo er abbricht.
Die Zertifikate aus <layout>\certificates\ müssen vorher in den Zertifikatspeicher. Ein frisches Windows ohne Netz kann die Root-Zertifikate nicht per Windows Update nachladen, die Signaturprüfung scheitert dann mit einer Meldung, die kein Wort über Zertifikate verliert.
Erneutes --layout auf denselben Ordner lädt nur die Differenz. --verify und --fix prüfen und reparieren ein unvollständiges Layout.

MSBuild finden

MSBuild liegt nicht im PATH. Voller Pfad ist Pflicht.
Build Tools installieren nach C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\, die IDE-Editionen nach C:\Program Files\Microsoft Visual Studio\2022\<Edition>\, ohne (x86).
vswhere.exe liegt immer unter C:\Program Files (x86)\Microsoft Visual Studio\Installer\ und liefert den Pfad: -products * -requires Microsoft.Component.MSBuild -find MSBuild\**\Bin\MSBuild.exe.

Layout-Ablage

Das Layout ist mehrere GB, jedes Update legt den nächsten Block dazu, Git dedupliziert nichts. Gehört nicht in ein Repo, das beim VM-Bau geklont wird.
Das Layout vom Linux-Host aus zu spiegeln ginge über das Channel-Manifest und dessen catalog.json. Das Format ist aber keine zugesagte Schnittstelle. Der Ausfall käme dann, wenn dringend eine VM gebraucht wird.

Build per SSH

Pre- und PostBuildEvents laufen mit und erzeugen oft einen Teil der Artefakte. Ein fehlschlagendes PostBuildEvent ist kein Compilerfehler.
%DATE% und %TIME% hängen am Gebietsschema des Kontos, unter dem der SSH-Dienst läuft. Skripte, die daraus Dateinamen oder Versionen bauen, liefern ein anderes Format als bei interaktivem Login.

Ich hab da eine noch unausgegorene Idee, plus die Learnings aus einer ersten Recherche. # Idee - Die VM als Buildserver für .NET-Solutions, die noch auf .NET Framework und WPF laufen. - Ablauf: Repo per `scp` rein, per SSH einloggen, ein MSBuild-Aufruf, Ergebnis zurückgeben, fertig. - Bedingung: kein Internet für den Container. Windows macht dann bloß Blödsinn wie 80% der verfügbaren Ressourcen in Updates stecken, wo der einzige Auftrag "bau das Projekt" ist. ## Learnings - reicht vllt. nur die .NET-Framework SDK? => leider nein - VS 2022 oder neuer? VS 2022 aus Gewohnheit. # Learnings, Zusammenfassung von CLaude, runtergebrochen ## Was das .NET-Framework-SDK nicht kann - Das Developer Pack liefert Reference Assemblies. Kein MSBuild, kein Compiler, keine WPF-Targets. - `dotnet build` versteht klassische `.csproj` nicht. Nur `MSBuild.exe`. - Was fehlt, liefern die VS Build Tools, Workload `ManagedDesktopBuildTools`, dazu je ein Targeting Pack pro vorkommender Framework-Version. - Die Build Tools sind lizenzrechtlich für Buildserver gedacht. VS Community ist es nicht. ## Offline-Installation - `vs_BuildTools.exe --layout` lädt ein vollständiges Offline-Paket herunter, aus dem danach ohne Netz installiert wird. - `--layout` ist eine Windows-EXE. Läuft nicht auf Linux, Wine ist für den VS-Installer aussichtslos. Es braucht also einmalig eine Windows-Kiste mit Netz. - `--lang` weglassen zieht alle Sprachpakete und bläht das Layout um ein Vielfaches auf. - `--noWeb` bei der Installation weglassen schickt den Installer trotz fertigem Layout ins Netz, wo er abbricht. - Die Zertifikate aus `<layout>\certificates\` müssen vorher in den Zertifikatspeicher. Ein frisches Windows ohne Netz kann die Root-Zertifikate nicht per Windows Update nachladen, die Signaturprüfung scheitert dann mit einer Meldung, die kein Wort über Zertifikate verliert. - Erneutes `--layout` auf denselben Ordner lädt nur die Differenz. `--verify` und `--fix` prüfen und reparieren ein unvollständiges Layout. ## MSBuild finden - MSBuild liegt nicht im `PATH`. Voller Pfad ist Pflicht. - Build Tools installieren nach `C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\`, die IDE-Editionen nach `C:\Program Files\Microsoft Visual Studio\2022\<Edition>\`, ohne `(x86)`. - `vswhere.exe` liegt immer unter `C:\Program Files (x86)\Microsoft Visual Studio\Installer\` und liefert den Pfad: `-products * -requires Microsoft.Component.MSBuild -find MSBuild\**\Bin\MSBuild.exe`. ## Layout-Ablage - Das Layout ist mehrere GB, jedes Update legt den nächsten Block dazu, Git dedupliziert nichts. Gehört nicht in ein Repo, das beim VM-Bau geklont wird. - Das Layout vom Linux-Host aus zu spiegeln ginge über das Channel-Manifest und dessen `catalog.json`. Das Format ist aber keine zugesagte Schnittstelle. Der Ausfall käme dann, wenn dringend eine VM gebraucht wird. ## Build per SSH - Pre- und PostBuildEvents laufen mit und erzeugen oft einen Teil der Artefakte. Ein fehlschlagendes PostBuildEvent ist kein Compilerfehler. - `%DATE%` und `%TIME%` hängen am Gebietsschema des Kontos, unter dem der SSH-Dienst läuft. Skripte, die daraus Dateinamen oder Versionen bauen, liefern ein anderes Format als bei interaktivem Login.

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

Christian/Win11-VM-auto-build-and-start#1

No description provided.

Rows
Columns