Typische Kandidaten
VC++ Redistributables, .NET Desktop Runtime, ASP.NET Runtime, WebView2, Edge WebView, Java, SQL LocalDB und Treiberpakete tauchen regelmaessig als stille Vorbedingung auf.
Unsichtbarer Fehler
Ein Setup kann mit Exitcode 0 enden und spaeter trotzdem unbrauchbar sein, wenn die Anwendung beim ersten Start auf fehlende Komponenten laeuft.
MEM-Perspektive
Dependencies sind nicht nur technische Vorarbeit. Sie beeinflussen Reihenfolge, Detection, Supersedence und Fehlersuche im Deployment-Tool.
Zu MEM / SCCMMSIX-Sonderfall
Gerade bei MSIX muessen Framework-Pakete, Zertifikate und Provisioning-Kontext bewusst geprueft werden.
MSIX lesenPrueffragen
Woran man fehlende Voraussetzungen erkennt
Dependencies stehen selten sauber im Dateinamen. Man muss sie aus Verhalten, Logs und Herstellerhinweisen ableiten.
Installer bringt weitere Setups mit
Wenn Child-Prozesse fuer vcredist, dotnet, dxsetup oder Treiber auftauchen, ist das keine Randnotiz, sondern Teil des Paketdesigns.
Anwendung startet erst nach Reboot oder First Run
Dann reicht ein reiner Install-Test nicht. Der Pakettest muss die reale Nutzbarkeit nach der Installation pruefen.
Log nennt fehlende DLLs oder Frameworks
Fehlermeldungen zu Runtime-Komponenten, COM-Registrierung oder Browser-Embedded-Komponenten sind haeufig der eigentliche Bruchpunkt.
Vendor-Doku spricht von System Requirements
Diese Angaben gehoeren in die Paketanalyse. Nicht alles davon wird automatisch mitinstalliert.
Vor jedem Paket pruefen:
- Welche Runtime oder Plattform wird erwartet?
- Wird sie vom Hersteller-Setup mitgebracht oder nur vorausgesetzt?
- Wie wird die Dependency erkannt?
- Muss sie separat versioniert und aktualisiert werden?Strategie
Wie Dependencies paketiert werden sollten
Die Entscheidung ist nicht nur technisch. Sie bestimmt Wartbarkeit und spaetere Updatefaehigkeit.
Separat paketieren, wenn die Komponente geteilt wird
VC++ Runtimes, WebView2 oder .NET gehoeren oft als eigene Pakete behandelt, damit sie versionsbezogen gepflegt und mehrfach genutzt werden koennen.
Im Hauptpaket belassen, wenn es eng gekoppelt ist
Herstellerspezifische Treiber, Hilfsdienste oder Setup-Bausteine koennen Teil desselben Pakets bleiben, wenn sie ohne Hauptanwendung keinen eigenen Wert haben.
Detection fuer die Voraussetzung separat denken
Eine App-Detection beweist nicht, dass die Runtime korrekt vorhanden ist. Fuer kritische Dependencies braucht es einen eigenen Nachweis.
Detection Recipes lesenUpgradepfad frueh mitdenken
Dependencies koennen spaeter Supersedence, Reparaturen und Konflikte mit aelteren Versionen ausloesen.
Updates und Supersedence lesenTypischer Fehler
Das Hauptsetup wird sauber getestet, aber der erste App-Start, ein Plugin oder ein Benutzerkontext fehlt im Test. Dadurch bleibt eine echte Abhaengigkeit unentdeckt.
Architektur mitpruefen
Gerade bei Runtimes und Redistributables fuehrt eine falsche 32/64-Bit-Annahme spaeter zu schwer lesbaren Fehlerbildern.
32/64-Bit-Fallen lesenTrust nicht vergessen
Wenn Abhaengigkeiten separat verteilt werden, muessen auch Signaturen, Publisher und Quellen bewertet werden.
Security und Trust lesenCheckliste fuer die Freigabe
Dependencies gehoeren ausdruecklich in die Freigabepruefung, sonst tauchen sie erst im produktiven Rollout wieder auf.
Deployment-Checkliste lesen