Solution-Patches in Dataverse zusammenführen: Merge, Clone und der ehrliche ALM-Weg

Irgendwann ist es so weit: Auf deiner Solution liegen drei, vier Patches, jeder mit einer kleinen Änderung, und du willst sie endlich zu einer sauberen, neuen Version zusammenführen. Die Frage im Maker Portal ist dann schnell da — „Clone a Patch” oder „Clone Solution”? — und die Antworten im Netz widersprechen sich.

Die kurze Version: Patches sind ein Werkzeug für kleine, schnelle Nachträge. Zusammengeführt werden sie über Clone Solution in eine neue Base-Version. Und für alles, was im Team läuft, empfiehlt Microsoft selbst einen anderen Weg. Der Reihe nach.

Erst klären: managed oder unmanaged?

Das ist die eine Frage, die alles entscheidet — beantworte sie zuerst.

• Im Entwicklungs-Environment arbeitest du mit unmanaged Solutions. Hier entsteht deine Anpassung, hier liegen die Komponenten „offen”.
• In Test/Prod installierst du managed Solutions. Managed heißt: gekapselt, nicht direkt editierbar, sauber deinstallierbar.

Patches gibt es in beiden Welten — aber ihr Sinn und ihre Merge-Folgen unterscheiden sich. Wenn du im Dev unmanaged arbeitest (der Normalfall), ist „Patch zusammenführen” vor allem eine Frage der Versionsführung deiner Quell-Solution, nicht des Ziel-Environments.

Was ist ein Patch überhaupt?

Ein Patch ist eine untergeordnete Solution zu einer Parent-Solution. Er enthält nur die Teilkomponenten, die du nachträglich änderst — nicht die ganze Tabelle mit allem Drumherum. Erzeugt wird er nicht durch normales Bearbeiten, sondern gezielt: im Maker Portal über „Clone a Patch”, per Code über die Message CloneAsPatchRequest (CloneAsPatch).

Zwei Dinge, die dich sonst kalt erwischen:

1. Sobald ein Patch existiert, ist die Parent-Solution gesperrt. Du kannst sie nicht mehr ändern oder exportieren, solange abhängige Patches dranhängen. Ab jetzt lebt deine Arbeit in den Patches.
2. Die Version muss steigen. Ein Patch braucht eine höhere Versionsnummer als die Base. Importierst du einen Patch mit niedrigerer Version, quittiert Dataverse das mit Fehler 80048539 – „invalid patch”.

Wie Dataverse überhaupt mergt

„Zusammenführen” passiert in Dataverse ständig — über Solution Layering. Jede Komponente hat Schichten: die managed Layer der installierten Solutions unten, deine unmanaged Anpassung oben. Für die meisten Komponenten gilt: die oberste Schicht gewinnt (last writer wins pro Komponente). Ein Patch legt sich als Schicht über die Base — deshalb überschreibt er sie punktuell.

Ein paar Komponenten mergen aber anders, und genau hier entstehen die bösen Überraschungen:

• Forms mergen section-by-section. Nicht das ganze Form wird ersetzt, sondern nur die geänderten Abschnitte werden mit dem Ziel-Form verschmolzen. Fügst du Felder in eine bestehende Section ein, kann deine unmanaged Schicht darüberliegende managed Elemente verdecken. Faustregel: eigene Felder in eine neue Section/neuen Tab kapseln, dann bleibt der Merge sauber.
• Merge-Konflikte landen im „Conflicts Tab”. Wenn Form-Komponenten nicht sauber verschmolzen werden können, legt Dataverse beim Import automatisch einen Conflicts Tab aufs Form und parkt die betroffenen Elemente dort — nichts geht verloren, aber du musst sie manuell wieder platzieren und den Tab dann entfernen. Typische Auslöser: dieselbe Section in Quelle und Ziel geändert, oder zwei Solutions vergeben denselben Ordinal-Wert.
• Choice-Columns sind additiv. Optionen aus einer managed Solution kommen hinzu; beim Deinstallieren verschwinden sie wieder. Der Option Value Prefix (aus dem Publisher-Prefix) verhindert Kollisionen der Optionswerte.
• Custom Security Roles werden ersetzt, nicht gemergt. Das ist by design: Ein Import überschreibt die Privilegien der Rolle komplett mit denen aus der Solution. Konsequenz: verwalte eine Custom Role immer aus derselben Solution — sonst gehen Privilegien-Updates aus einer anderen Solution verloren. Und: Predefined (Out-of-the-box) Roles nie per Custom-Solution anfassen — kopiere die Rolle lieber und pflege die Kopie.

Patches zusammenführen — der eigentliche Merge

Jetzt der Kern: Du willst die Patches loswerden und alles in eine neue Base-Version gießen. Das macht Clone Solution (Message CloneAsSolutionRequest / CloneAsSolution):

Clone Solution rollt die Parent-Solution samt aller zugehörigen Patches in eine neue Base-Solution mit höherer Version — und entfernt dabei die ursprüngliche Solution und ihre Patches.

Damit sind aus „Base 1.0 + Patch 1.0.1 + Patch 1.0.2” wieder eine konsolidierte „Base 2.0”. Der Weg im Maker Portal:

1. Sichern zuerst. Exportiere die aktuelle Parent-Solution (und/oder jeden Patch) als Backup, bevor du irgendetwas rollst. Clone ist nicht umkehrbar.
2. Solutions öffnen → die Parent-Solution auswählen → Clone Solution.
3. Neue Versionsnummer vergeben (höher als alles Bisherige).
4. Bestätigen — Dataverse merged Base + Patches, entfernt die alten Artefakte und legt die neue Base an.
5. Ergebnis prüfen: Enthält die neue Base wirklich alle Änderungen aus allen Patches? Ein kurzer Blick über Solution Layers („see solution layers”) zeigt dir je Komponente, welche Schicht am Ende zieht.

Zum Upgrade ins Zielsystem gilt das Übliche: Beim Import einer neuen managed Version wählst du „Upgrade” — das rollt die Änderungen zusammen und räumt entfernte Komponenten mit auf; „Update” oder „Stage for upgrade” verhalten sich anders. Für Forms greift die Overwrite Customizations-Option übrigens nicht — Form-Layer werden immer gemerged.

Der ehrliche Haken: Wann Patches — und wann besser nicht

Hier trennt sich schnelle Notlösung von belastbarem Prozess. Microsoft schreibt es selbst deutlich:

„Clone a Patch” und „Clone Solution” zum Aktualisieren einer Solution zu verwenden, wird nicht empfohlen — es behindert Team-Entwicklung und erhöht die Komplexität.

Der Grund: Sobald der Parent gesperrt ist und alles in Patches lebt, arbeiten mehrere Leute schlecht parallel, und die Historie steckt in Dataverse statt in deinem Repo. Für alles jenseits eines einzelnen schnellen Hotfixes ist der moderne ALM-Weg die bessere Wahl:

• Unmanaged Dev-Solution im Entwicklungs-Environment, Komponenten segmentiert.
• Source Control als Wahrheit: die Solution als entpacktes Projekt (z. B. via pac solution clone / pac solution sync) ins Git.
• Managed Build aus dem Repo, deployt über Pipelines (Power Platform Pipelines / Azure DevOps / GitHub) als Upgrade nach Test und Prod.

Kurz: Patches sind für den einen kleinen, dringenden Nachtrag auf einer Version, die schon draußen ist. Versionierte Upgrades aus Source Control sind für alles, was regelmäßig und im Team passiert.

Fallstricke, die dich sonst Zeit kosten

• Parent-Lock: Solange Patches existieren, ist die Base gesperrt. Willst du wieder frei an der Base arbeiten, musst du erst per Clone konsolidieren.
• Versionsnummern: Patch > Base, neue Base > alles. Sonst 80048539.
• „Changes aren’t effective after import”: Vergiss das Publish nicht — sonst wirken Anpassungen im Ziel nicht.
• Forms: eigene Elemente kapseln (neue Section/Tab), sonst Conflicts Tab und verdeckte managed Felder.
• Security Roles: Custom Roles immer aus einer Solution pflegen; Predefined Roles nie direkt in Custom-Solutions ändern.
• Backup: Vor jedem Clone exportieren. Der Roll-up entfernt die Originale.

Fazit: der Merksatz

Zwei Sätze, die dir die Entscheidung abnehmen:

1. Zusammenführen = Clone Solution. Er rollt Base + alle Patches in eine neue Base-Version und räumt die Patches weg — vorher sichern.
2. Für Team und Regelbetrieb: kein Patch-Gebastel, sondern Source Control + versioniertes Upgrade. Patches bleiben die Ausnahme für den schnellen Einzel-Fix.