Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Wenn Sie eine Tabelle einer Lösung hinzufügen und die Lösung exportieren, werden die Tabelle und alle ihre verknüpften Objekte in die Lösung exportiert. Diese Objekte umfassen Spalten (Attribute), Formulare, Ansichten, Beziehungen und Visualisierungen und alle anderen Objekte, die zusammen mit der Tabelle ausgeliefert wurden. Alle Objekte zu exportieren bedeutet, dass Sie unbeabsichtigt Objekte in der Zielbereitstellung ändern können oder unbeabsichtigte Abhängigkeiten übertragen können.
Um diese Abhängigkeiten zu lösen, können Sie entweder Lösungspatches erstellen und veröffentlichen, die Unterkomponenten von Tabellen enthalten, anstatt eine vollständige Tabelle und alle ihre Objekte zu erstellen. Die ursprüngliche Lösung und eines oder mehrere verknüpfte Patches können zu einem späteren Zeitpunkt als Rollup (Zusammenführung) in einer aktualisierten Version bereitgestellt werden, die dann die ursprüngliche Lösung in der Ziel-Microsoft Dataverse-Organisation ersetzt.
Patches
Sie können entweder Patches auf verwaltete oder nicht verwaltete Lösungen anwenden und nur Änderungen an Tabellen und verknüpften Tabellenobjekten einfügen. Patches enthalten keine nicht-angepassten Systemkomponenten oder -beziehungen, von denen sie abhängen, da diese Komponenten bereits in der Organisation vorhanden sind, für die sie bereitgestellt wurden. Zu einem bestimmten Zeitpunkt in Ihrem Bereitstellungszyklus können Sie ein Rollup aller Patches in eine neue Lösungsversion durchführen, um die ursprüngliche Lösung zu ersetzen, aus der heraus die Patches erstellt wurden.
Patches werden in der Dataverse-Datenbank als Solution-Tabellendatensätze gespeichert. Ein Nicht-null-Attribut ParentSolutionId gibt an, dass die Lösung ein Patch ist. Patches können durch das SDK für .NET oder Web-APIs erstellt und verwaltet werden. Diese sind nützlich für die Entwicklung von Automatisierung, wie beispielsweise ein Produktinstallationsskript. Allerdings stellt die Dataverse-Webanwendung verschiedene Webformulare bereit, mit denen Sie Patches interaktiv erstellen und verwalten können.
- Patches können nur von einer übergeordneten Lösung erstellt werden, indem Sie die CloneAsPatchRequest oder CloneAsPatch Aktion verwenden.
- Der übergeordnete Patch kann kein Patch sein.
- Patches können nur eine übergeordnete Lösung haben.
- Ein Patch erstellt eine Abhängigkeit (auf Lösungsebene) für seine übergeordnete Lösung.
- Sie können nur ein Patch erstellen, wenn die übergeordnete Lösung vorhanden ist.
- Sie können keinen Patch installieren, es sei denn ein eindeutiger Name und eine Haupt-/Nebenversionsnummer der übergeordneten Lösung wie sie von
ParentSolutionIdidentifiziert wird, stimmen nicht mit denen der übergeordneten Lösung überein, die in der Zielorganisation installiert ist. - Eine Patchversion muss dieselbe Haupt- und Nebennummer haben, aber eine höhere Build- und Versionsnummer als die Versionsnummer der übergeordneten Lösung. Der Anzeigename kann unterschiedlich sein.
- Wenn eine Lösung über Patches verfügt, müssen darauf folgende Patches eine numerisch höhere Versionsnummer als alle vorhandenen Patches für diese Lösung haben.
- Patches unterstützen dieselben Vorgänge wie Lösungen, wie beispielsweise additive Updates, aber nicht das Entfernen. Sie können mithilfe eines Patches keine Komponenten aus einer Lösung entfernen. Zum Entfernen von Komponenten aus einer Lösung müssen Sie ein Upgrade durchführen.
- Patches, die als verwaltet exportiert werden, müssen zusätzlich zu einer verwalteten übergeordneten Lösung importiert werden. Die Regel besagt, dass Patchschutz (verwaltet oder unverwaltet) der übergeordneten Ebene entsprechen muss.
- Verwenden Sie keine unverwalteten Patches für Produktionszwecke.
Die SolutionPackager- und PackageDeployer-Tools in dieser Version unterstützen Lösungspatches. Weitere Informationen erhalten Sie in der Onlinehilfe des Tools für alle Befehlszeilenoptionen, die mit Patches verknüpft sind.
Einen Patch erstellen
Erstellen Sie einen Patch aus einer nicht verwalteten Lösung in einer Umgebung, indem Sie die CloneAsPatchRequest-Meldung oder die CloneAsPatch-Aktion verwenden oder mithilfe der Webanwendung. Sobald Sie einen Patch erstellen, wird die ursprüngliche Version gesperrt und Sie können sie nicht mehr ändern oder exportieren, so lange es abhängige Patches gibt, die in der Umgebung vorhanden sind, die die Lösung als die übergeordnete Lösung identifizieren. Patchversionsverwaltung ähnelt der Lösungsversionsverwaltung und ist im folgenden Format angegeben: major.minor.build.release. Sie können keine Änderungen an den vorhandenen Haupt- oder Nebenlösungsversionen vornehmen, wenn Sie einen Patch erstellen.
Exportieren und Importieren eines Patches
Verwenden Sie das SDK für .NET- oder Web-APIs, die Webandwendung oder das Package Deployer Tool verwenden, um einen Patch zu exportieren und zu importieren. Die relevanten SDK für .NET-Anforderungsklassen sind ImportSolutionRequest und ExportSolutionRequest. Die relevanten Aktionen für die Web-API sind ImportSolution-Aktion und ExportSolution-Aktion.
Beispiele fürs Patchen
In der folgenden Tabelle sind die Details des Beispiels eines Patchvorgangs aufgeführt. In diesem Beispiel werden die Lösung und Patches in numerischer Reihenfolge importiert und sind additiv, das ist in Übereinstimmung mit dem Lösungsimport im Allgemeinen.
| Patchname | Beschreibung |
|---|---|
SolutionA Version 1.0 (unverwaltet) |
Enthält entityA mit sechs Feldern. |
SolutionA Version 1.0.1.0 (unverwaltet) |
Enthält entityA mit 6 Feldern (3 aktualisiert) und fügt entityB mit 10 Feldern hinzu. |
SolutionA Version 1.0.2.0 (unverwaltet) |
Enthält entityC mit 10 Feldern. |
Der Importvorgang ist wie folgt.
- Der Entwickler oder Anpasser importiert zuerst die Basislösung (
SolutionA1.0) in die Umgebung. Das Ergebnis istentityAmit sechs Feldern in der Umgebung. - Anschließend wird das
SolutionA-Patch 1.0.1.0 importiert. Die Umgebung enthält nunentityAmit sechs Feldern (drei wurden aktualisiert), sowieentityBmit 10 Feldern. - Zuletzt wird
SolutionA-Patch 1.0.2.0 importiert. Die Umgebung enthält nunentityAmit sechs Feldern (drei wurden aktualisiert), sowieentityBmit 10 Feldern undentityCmit 10 Feldern.
Ein weiteres Beispiel für einen Patchvorgang:
Betrachten wir nun ein weiteres Beispiel für einen weiteren Patchvorgang. abei werden die Details in der folgenden Tabelle aufgelistet.
| Patchname | Beschreibung |
|---|---|
SolutionA Version 1.0 (unverwaltet, Basislösung) |
Enthält die Account-Tabelle, bei der die Länge des Kontonummernspalte von 20 auf 30 Zeichen angepasst wird. |
SolutionB Version 2.0 (nicht verwaltet, anderer Zulieferer) |
Enthält die Account-Tabelle, bei der die Länge des Kontonummernspalte auf 50 Zeichen angepasst wird. |
SolutionA Version 1.0.1.0 (unverwaltet, Patch) |
Enthält ein Update auf die Account-Tabelle, bei der die Länge der Kontonummernspalte auf 35 Zeichen angepasst wird. |
Der Importvorgang ist wie folgt:
- Der Entwickler oder Anpasser importiert zuerst die Basislösung (
SolutionA1.0) in die Umgebung. Das Ergebnis ist eineAccount-Tabelle mit einer Kontonummernspalte von 30 Zeichen. -
SolutionBist Importiert. Die Umgebung enthält nun eineAccount-Tabelle mit einer Kontonummernspalte von 50 Zeichen. -
SolutionA-Patch 1.0.1.0 wird importiert. Die Umgebung enthält immer noch eineAccount-Tabelle mit einer Kontonummernspalte von 50 Zeichen, wie durchSolutionBangewendet. -
SolutionBwurde deinstalliert. Die Umgebung enthält nun eineAccount-Tabelle mit einer Kontonummernspalte von 35 Zeichen, wir durch dasSolutionA1.0.1.0-Patch angewendet.
Ein Patch löschen
Sie können einen Patch oder eine Basis-(übergeordnete)-Lösung löschen, indem Sie DeleteRequest verwenden oder, für die Web-API, die HTTP DELETE-Methode verwenden. Der Löschvorgang ist bei einer verwalteten und einer nicht verwalteten Lösung, bei der eine oder mehrere Patches in der Umgebung vorhanden sind, unterschiedlich.
Für eine nicht verwaltete Lösung müssen Sie alle Patches der Basislösung zuerst löschen, in der umgekehrten Versionsreihenfolge, als in der sie erstellt wurden, bevor Sie die Basislösung deinstallieren.
Für eine verwaltete Lösung deinstallieren Sie einfach die Basislösung. Das Dataverse-System deinstalliert automatisch die Patches in umgekehrter Versionsreihenfolge, bevor die Basislösung deinstalliert wird. Sie können auch einfach einen einzelnen Patch deinstallieren.
Eine Lösung aktualisieren
Beim Aktualisieren einer Lösung wird ein Rollup (Zusammenführung) aller Patches für diese Lösung in eine neue Version der Lösung ausgeführt. Danach wird die Lösung entsperrt und kann erneut geändert werden (nur nicht verwaltete Lösung) oder exportiert werden. Für eine verwaltete Lösung sind keine weiteren Änderungen der Lösung zulässig, außer wenn Patches aus der neu aktualisierten Lösung erstellt werden. Wenn Sie einen Rollup für Patches in eine nicht verwaltete Lösung ausführen, verwenden Sie CloneAsSolutionRequest oder die CloneAsSolution-Aktion. Beim Clonen einer Lösung wird eine neue Version der nicht verwalteten Lösung erstellt. Dabei werden alle ihre Patches einbezogen, mit einer höheren major.minor-Versionsnummer, demselben eindeutigen Namen und einem Anzeigename.
Bei einer verwalteten Lösung wird etwas anders vorgegangen. Zuerst klonen Sie die nicht verwaltete Lösung (A), binden alle ihre Patches ein und exportieren sie dann als eine verwaltete Lösung (B). In der Zielorganisation, die die verwaltete Lösung der (A) Lösung und ihre Patches umfasst, importieren Sie die verwaltete Lösung (B) und führen dann DeleteAndPromoteRequest oder die DeleteAndPromote-Aktion aus, um die verwaltete Lösung (A) und ihre Patches mit der aktualisierten verwalteten Lösung (B) zu ersetzen, die eine höhere Versionsnummer hat.