Solution Import scheitert mit missing dependency: Ursachen finden und beheben

Ein Solution-Import in Dynamics 365 bricht mit der Meldung Import failed due to missing dependencies oder mit einem Verweis auf components missing (Active) ab, wenn die Solution auf eine Komponente verweist, die in der Zielumgebung nicht existiert. Diese Komponente kann eine Tabelle, eine Spalte, eine Ansicht, ein Formular, ein Flow oder eine ganze abhängige Solution sein. Die Solution selbst ist dabei meist nicht defekt: Es fehlt der Unterbau, auf dem sie aufsetzt. Dieser Artikel zeigt die typischen Ursachen, wie Sie die fehlende Abhängigkeit sicher aufspüren und mit welchen Fixes Sie den Import zum Erfolg bringen.

Der Fehler gehört zu den häufigsten Stolpersteinen im Solution-Lebenszyklus. Wie er in das größere Bild passt, beschreibt unser Überblick zum Solution-Modell und ALM in Dynamics 365.

Was der Fehler missing dependency bedeutet

Beim Export einer Solution berechnet Dataverse alle Komponenten, von denen die enthaltenen Objekte abhängen, die aber selbst nicht Teil der Solution sind. Diese Liste landet im Element MissingDependencies in der Datei solution.xml. Beim Import prüft die Zielumgebung, ob jede dieser Abhängigkeiten dort vorhanden ist. Fehlt auch nur eine, wird der Import abgebrochen, bevor irgendetwas geschrieben wird.

Das ist ein bewusster Schutzmechanismus, kein Bug. Eine Solution, die auf eine Spalte verweist, die es in der Zielumgebung nicht gibt, würde dort zu inkonsistenten Metadaten führen. Statt einen halb importierten Zustand zuzulassen, verlangt Dataverse, dass Sie zuerst den fehlenden Unterbau bereitstellen.

Die häufigsten Ursachen

Fast alle Fälle lassen sich auf vier Muster zurückführen. Wer das richtige Muster erkennt, wählt den passenden Fix.

Fehlende abhängige Komponenten

Der Regelfall: Ein Objekt in Ihrer Solution verweist auf eine Tabelle, eine Spalte, ein Optionsset oder eine Ansicht, die in der Zielumgebung nicht existiert. Häufig ist die Ursache eine Unmanaged-Anpassung in der Quellumgebung, die nie in eine Solution aufgenommen wurde. Genau hier erscheint die Meldung components missing (Active), denn Active bezeichnet die Unmanaged-Ebene, also die Default Solution der Umgebung.

Falsche Reihenfolge der Solutions

Arbeiten Sie mit mehreren managed Solutions, gilt eine feste Regel: Basis vor Erweiterung. Eine Solution, die Komponenten einer anderen managed Solution nutzt, lässt sich erst importieren, wenn diese Basis bereits in der Zielumgebung installiert ist. Fehlt die Basis, meldet Dataverse die Abhängigkeit im Abschnitt Managed Solutions.

Unterschiedliche Umgebungen und Versionen

Wurde die Quellumgebung durch Microsoft-Wartung auf eine neuere App- oder Dataverse-Version gehoben, die Zielumgebung aber nicht, kann Ihre Solution auf Komponenten verweisen, die es in der älteren Zielversion noch nicht gibt. Dieses Muster tritt gern nach automatischen Updates auf und lässt sich nur durch angeglichene Versionen zuverlässig vermeiden.

Ungewollte Unmanaged-Layer

Wird eine managed Komponente direkt in der Umgebung geändert, entsteht darüber ein Unmanaged-Layer. Dieser Layer kann eigene Abhängigkeiten mitbringen, die beim nächsten Export als fehlend gemeldet werden. Deshalb rät Microsoft, Änderungen immer in einer eigenen Unmanaged-Solution vorzunehmen statt direkt am managed Objekt.

Die fehlende Abhängigkeit finden

Bevor Sie etwas reparieren, brauchen Sie den genauen Namen und Typ der fehlenden Komponente. Es gibt zwei verlässliche Wege.

Beim fehlgeschlagenen Import erscheint die Schaltfläche Show dependencies. Sie öffnet die Seite Missing dependencies, die alle fehlenden Teile in drei Kategorien sortiert: Applications, Managed Solutions und Unmanaged Components. Jeder Eintrag nennt Solution-Name, Version und Herkunft. Diese Einordnung ist entscheidend, denn sie bestimmt den passenden Fix. Bei fehlenden Anwendungen gibt es zusätzlich eine Schaltfläche Install oder Update, die in das Power Platform Admin Center führt.

Der zweite Weg funktioniert offline: Öffnen und entpacken Sie die exportierte Solution-Datei und suchen Sie in der Datei solution.xml nach dem Element MissingDependencies. Dort steht jede Abhängigkeit mit Komponententyp und Name. Das ist besonders nützlich in automatisierten Pipelines, wo Ihnen die grafische Oberfläche nicht zur Verfügung steht. Details und Screenshots liefert die Microsoft-Dokumentation zu Missing Dependencies During Solution Import.

Die passenden Fixes

Der richtige Schritt hängt davon ab, in welcher Kategorie die fehlende Komponente landet. Die folgende Tabelle ordnet die Fälle zu.

Bei den meisten Unmanaged-Fällen gehen Sie zurück in die Quellumgebung, fügen die fehlende Komponente der Solution hinzu, exportieren neu und importieren erneut. Handelt es sich um eine fehlende Basis-Solution, spielen Sie diese vorher ein, und zwar in exakt der Version, die in der Quelle installiert ist. Bei First-Party-Anwendungen kann Dataverse die benötigten Teile über die Option Deploy Dependencies teils automatisch installieren, bevor der eigentliche Import startet.

Vorbeugen mit sauberer Segmentierung

Die meisten missing dependency Fehler entstehen durch zu große Solutions. Wer beim Aktualisieren eine ganze Tabelle mit allen Objekten aufnimmt, obwohl nur eine Spalte geändert wurde, schleppt unnötige Abhängigkeiten mit und legt ungewollte Layer über bestehende Komponenten. Die Segmentierung löst das: Nehmen Sie nur die tatsächlich neuen oder geänderten Assets in die Solution auf.

Eine wichtige Ausnahme betrifft Tabellen, die in der Zielumgebung noch nicht existieren. Für eine ganz neue Tabelle müssen Sie die Option Include all objects wählen, sonst führt gerade das Segmentieren zum missing dependency Fehler. Bestehende Tabellen dagegen segmentieren Sie konsequent. Die Regeln dazu beschreibt Microsoft unter Table segmentation in solutions.

Ergänzend gelten drei Grundsätze, die Abhängigkeitsfehler dauerhaft reduzieren: alle Umgebungen auf derselben Dataverse- und App-Version halten, benötigte First-Party-Solutions vorab in jeder Zielumgebung installieren, und managed Komponenten nie direkt ändern, sondern nur über eine eigene Unmanaged-Solution erweitern. Gerade serverseitige Logik wie Plugins bringt eigene Abhängigkeiten mit, etwa auf registrierte SDK-Nachrichten oder Tabellen, die in der Zielumgebung vorhanden sein müssen.

Sonderfall Upgrade und Holding Solution

Beim Aktualisieren einer managed Solution wählen Sie zwischen Upgrade, Update und Stage for Upgrade. Die letzte Option legt neben der alten Version eine zusätzliche Solution mit dem Suffix _Upgrade an, die sogenannte Holding Solution. Sie erlaubt es, vor dem endgültigen Apply Solution Upgrade noch Daten zu migrieren, solange beide Versionen parallel installiert sind. Neuere Plattformversionen haben den einstufigen Upgrade allerdings so optimiert, dass keine temporäre _Upgrade-Solution mehr entsteht.

Für die Wahl zwischen den Optionen gilt: Upgrade räumt Komponenten auf, die nicht mehr Teil der neuen Version sind, und hält den Zielzustand konsistent. Update ist schneller, lässt aber entfernte Komponenten stehen und kann so die Umgebungen auseinanderlaufen lassen. Die genauen Unterschiede beschreibt Microsoft unter Update a solution. Wer vor einem Umzug Daten zwischen Umgebungen bewegt, findet den Rahmen dafür in unserem Leitfaden zur Dynamics 365 Datenmigration.

Wenn der Import trotzdem klemmt

Bleibt der Fehler bestehen, obwohl Sie die gemeldete Komponente bereitgestellt haben, liegt oft eine Kette dahinter: Die nachgezogene Komponente hat selbst eine Abhängigkeit, die wiederum fehlt. Arbeiten Sie die Missing-dependencies-Liste dann von unten nach oben ab, also von der Basis zur Erweiterung. Verlässlich vermeiden lässt sich das nur mit einer disziplinierten Solution-Architektur und angeglichenen Umgebungen. Wenn Ihre Deployments regelmäßig an Abhängigkeiten scheitern, sprechen Sie uns an. Wir prüfen Ihre Solution-Struktur und richten einen belastbaren ALM-Prozess ein.