Auf Englisch lesen

Freigeben über


BizTalk-Assemblys

Der wichtigste Aspekt von Microsoft BizTalk Server und .NET Framework ist, dass alle BizTalk Server-Elemente wie Zuordnungen, Schemas, Orchestrierungen und Pipelines in .NET-Assemblys kompiliert werden. Diese Vorgehensweise hat zur Folge, dass die Assemblys starke Namen erhalten müssen und deshalb außerdem .NET-Versionsregeln folgen. Aus diesem Grund verwendet ein BizTalk-Projekt, nachdem es für eine bestimmte Version eines anderen .NET-Projekts oder einer Assembly erstellt wurde (einschließlich BizTalk-Projekten), weiterhin diese Version, bis es für eine neuere Version neu erstellt wird.

.NET-Versionsverwaltung und Assemblys

Im Zusammenhang mit der .NET-Versionsverwaltung tritt während der Entwicklung häufig ein Problem auf, wenn die Versionsnummern eines BizTalk-Projekts nicht geändert werden und die Assembly erneut bereitgestellt wird, ohne dass die BizTalk-Hostinstanz, in die die Typen geladen werden, beendet und gestartet wird.

Bei erneuter Ausführung des Prozesses werden die Änderungen nicht wirksam. Der Grund dafür liegt im Verfahren, mit dem .NET-Assemblys in den Arbeitsspeicher geladen werden. Da bereits eine Kopie der Assembly in den Arbeitsspeicher des Hosts geladen wurde, wird die Assembly bei Ablage einer neuen Kopie im globalen Assemblycache nicht erneut geladen. Wird z. B. Version 1.0.0.0 einer Assembly mit einer Orchestrierung bereitgestellt und ausgeführt, und werden an der Orchestrierungen Änderungen vorgenommen, während die Versionsnummer gleich bleibt, werden die Änderungen nicht wirksam. Nach dem Beenden der Hostinstanz wird die im Arbeitsspeicher befindliche Kopie der Assembly freigegeben. Wenn die Hostinstanz neu startet, lädt sie die neue Kopie der Assembly und ruft die Änderungen ab. Das Bereitstellen und Laden einer neuen Version (z. B. Version 2.0.0.0) hätte eine Übernahme der Änderungen zur Folge gehabt.

Das Bereitstellen von Assemblys in BizTalk Server ist ein zweistufiger Prozess. In der ersten Stufe erfolgt die herkömmliche .NET-Assemblybereitstellung. Hierbei wird die Assembly mit starkem Namen im globalen Assemblycache (GAC) bereitgestellt, und zwar auf jedem Server, auf dem die Assembly verwendet werden soll. Im zweiten Schritt werden Metadaten zu Assemblys und ihren Typen in der BizTalk Server-Verwaltungsdatenbank bereitgestellt. Wenn BizTalk Server-Assemblys von BizTalk Server geladen werden, wird beim Laden meist der starke Name in der Verwaltungsdatenbank verwendet.

Bereitstellen von BizTalk Server-Assemblys im GAC

Die von einem Entwickler erstellten BizTalk Server-Elemente werden in Klassen kompiliert, die sich aus integrierten BizTalk Server-Typen ableiten. Eine Orchestrierung wird z. B. zu einer Klasse, die aus der Klasse "Microsoft.BizTalkXLANGs.BTXEngine.BTXService" abgeleitet wird. Da diese Basisklassen in Assemblys im globalen Assemblycache bereitgestellt werden, und weil für diese Assemblys Abhängigkeiten von anderen Assemblys im GAC bestehen, müssen die Assemblys eines Entwicklers ebenfalls im GAC bereitgestellt werden.

Die Tatsache, dass BizTalk Server-Elemente im globalen Assemblycache bereitgestellt und daher starke Namen erhalten müssen, hat eine weitere wichtige Auswirkung: Assemblys mit starkem Namen können andere Assemblys nicht aufrufen, wenn diese nicht ebenfalls einen starken Namen haben. Dies bedeutet, dass alle von einem Entwickler erstellten Assemblys, die von diesen BizTalk Server-Assemblys verwendet werden, ebenfalls starke Namen erhalten müssen. Ebenso gilt, dass im GAC bereitgestellte Assemblys, die andere Assemblys laden, ohne einen bestimmten Pfad zu verwenden, diese Assemblys aus dem GAC laden müssen.

Pipelinekomponenten werden der Toolbox eines Entwicklers in Visual Studio hinzugefügt, um sie zum Ziehen im Pipeline-Designer verfügbar zu machen. Beim Kompilieren einer BizTalk Server-Pipeline in eine .NET-Assembly werden die Informationen über alle Komponenten in den verschiedenen Stufen der Pipeline in die Assembly kompiliert. Wenn diese Pipeline für BizTalk Server bereitgestellt wird, werden die Informationen zu den Komponenten, einschließlich ihres Dateinamens, in die BizTalk Management-Datenbank eingefügt, und die Pipelineassembly wird im GAC bereitgestellt. Alle zusätzlichen Assemblys, von denen BizTalk-Pipelinekomponenten abhängen, müssen ebenfalls im GAC bereitgestellt werden, um zur Laufzeit gefunden zu werden. Pipelinekomponentenassemblys müssen in das Verzeichnis BizTalk Server\Pipeline Components kopiert werden, damit eine BizTalk-Pipeline zur Laufzeit darauf zugreifen kann, unabhängig davon, ob die Assembly auch im GAC bereitgestellt wird oder nicht. Bei Ausführung der Pipeline werden diese Komponenten geladen, und die Schnittstellen, die sie implementieren, werden entsprechend aufgerufen. Wenn auch eine Pipelinekomponentenassembly im GAC bereitgestellt wird, wird die Assembly zur Laufzeit aus dem GAC geladen. Dies kann zu Verwirrung führen, wenn nicht darauf geachtet wird, dass die Pipelinekomponentenassembly sowohl im Verzeichnis BizTalk Server\Pipeline Components als auch im GAC identisch ist.

Weitere Informationen

Architektur des Laufzeitmoduls