Versionsverwaltung bei BizTalk Server-Projekten
Bei der Entwicklung mit dem .NET Framework unterliegt die Versionsverwaltung einem Standardsatz von Regeln, die die Auswirkungen von Versionsnummernänderungen minimieren. Abhängig davon, wie eine .NET Framework-Anwendung oder -Komponente bereitgestellt wird, können Abhängigkeiten von einer Anwendungskonfigurationsdatei, über die XCOPY-Installation oder durch andere .NET Framework Bereitstellungsmechanismen verarbeitet werden. Wie in den folgenden Abschnitten gezeigt wird, erhöht BizTalk Server die Komplexität der Versionsverwaltung und der Abhängigkeiten.
Auswirkungen einer Änderung von Versionsnummern
In .NET Framework Entwicklung ist es üblich, die Versionsnummer der Assembly auf die aktuelle Buildnummer zu aktualisieren, wenn ein Build stattfindet. Beim Entwickeln einer BizTalk-Lösung kann eine Änderung der Versionsnummer der Assembly jedoch zu einer Unterbrechung der Beziehung zwischen einer Assembly und den von dieser abhängigen Elementen, die anhand der Versionsnummer der Assembly auf die DLL verweisen, zur Folge haben. In der folgenden Tabelle sind Elemente aufgeführt, die unter Verwendung der Versionsnummer und der Änderung einer Assemblyversionsnummer auf eine BizTalk Server Assembly verweisen.
| Entität | Auswirkungen des Änderns der Versionsnummer einer Assembly |
|---|---|
| Bindungsdateien | Wenn Sie die Versionsnummer einer Assembly ändern, treten bei den vorhandenen Bindungsdateien, die auf diese Assembly verweisen, Fehler auf. Ursache hierfür ist, dass die Bindungsdatei mit Attributen auf die Assembly verweist, die diese Versionsnummer beinhalten. Sie können die Versionsinformationen in der Bindungsdatei mit der Windows-Anwendung Editor oder einem anderen Editor aktualisieren. Sie können die Lösung auch erneut bereitstellen und dann die Bindungsdatei mithilfe der BizTalk Server-Verwaltungskonsole erneut generieren. Darüber hinaus besteht die Möglichkeit, die Bereitstellung und Versionsverwaltung mit Skripts zu automatisieren. Weitere Informationen zur Bereitstellung finden Sie unter Bereitstellen und Verwalten von BizTalk-Anwendungen. |
| BAM-Überwachungsprofildateien (.btt) | Wenn Sie die Versionsnummer einer Assembly ändern, treten bei den vorhandenen BAM-Überwachungsprofildateien Fehler auf. Die BAM-Überwachungsdateien liegen in einem binären Format vor und können daher nicht bearbeitet werden. Stattdessen müssen sie neu generiert werden. Wenn BAM-Überwachungsprofile erforderlich sind, müssen Sie unter Umständen einen der folgenden Punkte beachten: – Vermeiden Sie häufiges Aktualisieren von Versionsnummern während des Buildprozesses. – Verzögert die Erstellung von BAM-Nachverfolgungsprofilen, bis die Versionsnummern stabil sind. |
| Mit dem Assistenten für BizTalk-Webdienstpublishing veröffentlichte Webdienste | Wenn der Webdienstveröffentlichungs-Assistent verwendet wird, um eine ASP.NET Webschnittstelle zu erstellen, wird die Assemblyversion der BizTalk Server Assembly im ASP.NET Quellcode enthalten. Die Assemblyversionsnummer wird zur Laufzeit von der ASP.NET-Schnittstelle als Teil der bodyTypeAssemblyQualifiedName-Eigenschaft des Webdienstvorgangs verwendet. Wenn sich die Versionsnummer der BizTalk Server Assembly ändert, ohne die bodyTypeAssemblyQualifiedName-Eigenschaft zu aktualisieren, werden nachfolgende Webdienstvorgänge von BizTalk Server abgelehnt. Wenn der Empfangsspeicherort die XmlDefaultPipeline verwendet, basiert das Abonnement auf dem Dokumenttyp. Es verwendet in diesem Fall eingebettete Assemblyinformationen und schlägt fehl, wenn die Assembly nicht vorhanden ist. Wenn Sie die PassThruPipeline verwenden (die die Standardpipeline darstellt, wenn Sie einen Port offen legen und dem Assistenten die Erstellung des Empfangsspeicherorts überlassen), ignoriert das Abonnement diese eingebetteten Assemblyinformationen. |
Weitere Informationen zu BizTalk Server Assemblys und der Bereitstellung finden Sie unter BizTalk-Assemblys.
Ansätze zur Versionsverwaltung
Beim Planen eines Projekts haben Sie folgende Möglichkeiten:
Sie können eine feste Assemblyversion für eine bestimmte auszuliefernde Komponente auswählen und nur die Dateiversionsnummer erhöhen.
Sie können sowohl die Assemblyversion als auch die Dateiversion im Verlauf des Entwicklungsvorgangs erhöhen.
Diese beiden Ansätze werden einander in der nachstehenden Tabelle gegenüber gestellt.
| Feste Assemblyversion, dynamische Dateiversion | Dynamische Assemblyversion, feste oder dynamische Dateiversion |
|---|---|
| Versionsnummer der Assembly = Feste Nummer Versionsnummer der Datei = Buildnummer |
Versionsnummer der Assembly = Buildnummer Versionsnummer der Datei = Buildnummer |
| BizTalk Server Runtime kann die falsche Version der Assembly auswählen, wenn mehrere Assemblys installiert sind. | BizTalk Server führt immer die neueste Version der Assembly aus, auch wenn mehrere Assemblys installiert sind. |
| Nur eine Version der Lösung kann zu einem bestimmten Zeitpunkt installiert werden. | Unterschiedliche Versionen der Lösung können nebeneinander bereitgestellt werden (obwohl dabei andere Aspekte der Lösung, z. B. Schemadefinitionen, miteinander in Konflikt geraten können). |
| Der BizTalk-Host muss neu gestartet werden, um das Laden aktualisierter Assemblys zu erzwingen. | Erzwingt BizTalk Server, neue Assemblys zu laden. |
| Das Erstellen einer neuen Bereitstellung ist mit weniger Arbeitsaufwand verbunden, da Dateien, die auf die Versionsnummer der Assembly verweisen (z. B. Bindungsdateien und Überwachungsprofile), nicht bearbeitet werden müssen. | Die Bereitstellung ist mit einem höheren Arbeitsaufwand verbunden, da Dateien, die auf die Versionsnummer der Assembly verweisen, ständig auf die neue Version aktualisiert werden müssen. |
Möglicherweise entscheiden Sie sich in Situationen, in denen ein Prototyp von einem System erstellt werden soll oder Sie eine andere Art eines nicht für die Auslieferung gedachten Projekts entwickeln, für die Verwendung der festen Assembly- und dynamischen Dateiversion. Wenn die Anwendung nicht an Endbenutzer ausgeliefert wird, können Sie durch Fixieren der Assemblyversion und Erhöhen der Dateiversionsnummer Bereitstellungsaufgaben rationalisieren und Unterbrechungen bei Abhängigkeiten verringern. Bei der Versionsüberwachung müssen Sie daran denken, die Dateiversionsnummer für jeden Build zu erhöhen.
Wenn Sie ein Projekt erstellen, das an Endbenutzer ausgeliefert wird, sollten Sie das Erhöhen der Versionsnummer der Assembly und optional auch das Speichern einer aussagekräftigen Dateiversionsnummer in Erwägung ziehen. Bei dieser Methode fällt zwar mit dem Ändern der Buildnummern und der zugehörigen Abhängigkeiten ein zusätzlicher Aufwand an, jedoch wird hierbei die Verwendung der neuesten Versionen Ihrer Assemblys sichergestellt. Automatisierte Bereitstellungsskripts sorgen dafür, dass sich die Auswirkungen der Versionsverwaltung in Grenzen halten. Informationen zum Anzeigen von Bereitstellungsbeispielen finden Sie unter Anwendungsbereitstellung (BizTalk Server Beispielordner).
Hinweis
Sie sollten sich für den Mechanismus zur Versionsverwaltung entscheiden, bei dem die richtigen Dateien ausgeliefert und die Wartung und Verbesserung vereinfacht werden.
Versionsnummerierung bei der Zuordnungsfunktion
.NET-Assemblys können aus einer Zuordnung mithilfe des Skript-Funktoids aufgerufen werden. Dies bietet sehr viel Flexibilität und gibt dem Entwickler die Möglichkeit, zahlreiche unterschiedliche Zuordnungsprobleme zu lösen. Hierbei wird der Zuordnung außerdem eine einzigartige Einschränkung auferlegt, denn sie muss intern nicht nur auf den Namen des Assemblytyps sondern auch auf die vollständige Versionsnummer der aufzurufenden Assembly verweisen. Aus diesem Grund werden alle Verknüpfungen, die auf die Assembly verweisen, unterbrochen, wenn sich die Versionsnummer der von der Zuordnung aufgerufenen Assembly ändert.
Wenn Assemblys aus einer Zuordnung aufgerufen werden müssen, empfiehlt es sich, zur Vermeidung dieses Problems eine spezielle Assembly zu erstellen, die nur die Zuordnungsfunktion beinhaltet, und die Versionsnummer der Assembly zu fixieren. Auf diese Weise kann die Assemblyversion für andere Hilfsfunktionen aktualisiert werden, ohne dass die Zuordnungen unterbrochen werden.
Wenn eine Assembly, auf die von einer Zuordnung verwiesen wird, nach der Entwicklung der Zuordnung geändert wird, sollten Sie eine Aktualisierung der Zuordnungsdatei außerhalb des Zuordnungs-Editors in Erwägung ziehen, damit die aktualisierten Versionsnummern reflektiert werden.
So ändern Sie die Zuordnungsdatei mit dem Editor, damit die aktualisierten Versionsnummern reflektiert werden
Starten Sie im Startmenü Den Editor.
Klicken Sie im Editor im Menü Datei auf Öffnen. Wählen Sie im Dialogfeld Öffnen die Kartendatei aus, die Sie ändern möchten, und klicken Sie dann auf Öffnen.
Klicken Sie im Menü Bearbeiten auf Suchen. Geben Sie im Dialogfeld Suchenassembly= ein, und klicken Sie dann auf Weiter suchen.
Wenn es einen Skriptverweis auf eine externe Assembly gibt, müsste der Editor ein XML-Element finden, das dem folgenden ähnelt:
<Script Language="ExternalAssembly" Assembly="Contoso.Scripts, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c5145e4e089" Class="Contoso.Scripts" Function="CalculateValue" AssemblyPath="Contoso.Scripts.dll"/>Aktualisieren Sie die Versionsnummer. Wenn mehrere Instanzen vorhanden sind, verwenden Sie Ersetzen im Menü Bearbeiten .
Speichern Sie die Datei .
Sie können die Zuordnung nun mit dem Zuordnungs-Editor öffnen.
Weitere Informationen
Empfohlene Vorgehensweise für die Bereitstellung einer BizTalk-Anwendung
Admin (Ordner für BizTalk Server-Beispiele)
Programmgesteuertes Bereitstellen und Starten einer neuen Orchestrierungsversion