アプリケーションとアイテムの更新に関する既知の問題

アプリケーションを更新する

成果物を削除または削除しても、すべての場所から削除されるわけではありません

アイテムを削除すると、BizTalk Server データベースから削除され、管理コンソールまたは BTSTask ListApp コマンドで生成されるアプリケーションのアイテムの一覧には表示されなくなります。 これらの場所のいずれかに存在する場合、Windows レジストリ、グローバル アセンブリ キャッシュ (GAC)、仮想ディレクトリ、またはファイル システムから成果物は削除されません。 BizTalk 管理データベース内にのみ存在する送信ポート、送信ポート グループ、受信ポート、および受信場所の場合、アイテムはすべて削除されます。

アイテムの更新

成果物の状態を削除または変更すると、アプリケーションが動作しなくなる可能性があります

あるアプリケーションから別のアプリケーションに参照を追加し、別のアプリケーションが依存する成果物の状態を変更したり、成果物を削除したりすると、依存関係を持つアプリケーションは正しく機能しません。 成果物の状態の変更の詳細については、「成果物の 管理 (https://go.microsoft.com/fwlink/?LinkID=154725)」の適切な成果物に関するセクションを参照してください。

.NET ポリシー ファイルはサポートされていません

.NET ポリシー ファイルの使用は、BizTalk Serverではサポートされていません。 これは、ポリシー ファイルが予想どおりに機能しない場合があるためです。 ポリシー ファイルでは、GAC 内の指定されたアセンブリ バージョンに .NET がリダイレクトされますが、BizTalk Server は多くの場合、キャッシュまたは BizTalk 管理データベースにあるアセンブリおよびアイテムのデータにアクセスします。 アイテムの種類、キャッシュ状況、ホスト インスタンスの再開の有無によっては、ポリシー ファイルの動作が期待と異なる場合があります。

アセンブリの更新

ホストが停止していない場合、アセンブリに対する変更が有効にならない場合があります

BizTalk アセンブリは、.NET のバージョン管理規則に従う必要があります。 結果として、BizTalk のプロジェクトは、別の .NET プロジェクトまたはアセンブリ (BizTalk プロジェクトを含む) の特定のバージョンに対して構築されると、新しいバージョンに対して再構築されるまではそのバージョンを使い続けることになります。

.NET のバージョン管理に関連する開発中の問題は、BizTalk プロジェクトのバージョン番号を変更せず、型の読み込み先である BizTalk ホストのインスタンスを停止してから開始せずにアセンブリを再展開した場合によく発生します。

プロセスを再実行した場合、変更は適用されません。 これは、メモリへの .NET アセンブリの読み込み方法が原因です。 ホストにはアセンブリのメモリ内コピーが既に存在するため、新しいコピーがグローバル アセンブリ キャッシュ (GAC) に配置された場合、アセンブリは再読み込みされません。 たとえば、オーケストレーションのあるアセンブリのバージョン 1.0.0.0 を再展開して実行した場合、オーケストレーションに変更を加えても、バージョン番号を変更しなければ、変更は反映されません。 ホストのインスタンスを停止した後、メモリ内のアセンブリのコピーが解放され、ホストインスタンスが再開すると、アセンブリの新しいコピーを再度読み込んで変更を取り込みます。 新しいバージョン (バージョン 2.0.0.0 など) がデプロイされ、読み込まれた場合、変更は有効になります。

アセンブリのバージョンを変更すると、アセンブリとそれを参照するアイテムの間の関係がバージョン別に壊れる可能性があります

.NET Framework開発では、ビルドの実行時にアセンブリのバージョン番号を現在のビルド番号に更新するのが一般的です。 ただし、BizTalk ソリューションを開発する場合は、アセンブリ バージョン番号を変更すると、アセンブリと、そのアセンブリ バージョン番号を使って DLL を参照する依存アイテムの間の関係が壊れることがあります。 次の表に、バージョン番号を使用してBizTalk Server アセンブリを参照する項目と、アセンブリのバージョン番号を変更した結果を示します。

Entity	アセンブリ バージョン番号を変更することによる影響
バインド ファイル	アセンブリ バージョン番号を変更すると、そのアセンブリを参照するすべてのバインド ファイルは失敗します。 この理由は、バインド ファイルはアセンブリの参照に、バージョン番号を含む属性を使用するためです。 メモ帳などのエディターを使用して、バインド ファイルのバージョン情報を更新できます。 ソリューションを再デプロイしてから、BizTalk Server管理コンソールを使用してバインド ファイルを再生成することもできます。 スクリプトを使用して、展開とバージョン管理を自動化することもできます。 展開の詳細については、「 BizTalk アプリケーションの展開と管理 (https://go.microsoft.com/fwlink/?LinkID=154210)」を参照してください。
BAM 追跡プロファイル定義 (.btt) ファイル	アセンブリ バージョン番号を変更すると、既存の BAM 追跡プロファイルの定義ファイルは失敗します。 BAM 追跡ファイルはバイナリ ファイル形式であり編集できないので、再生成する必要があります。 BAM 追跡プロファイルが必須の場合は、次のいずれかの操作を行う必要があります。 - ビルド プロセス中にバージョン番号を頻繁に更新しないようにする - バージョン番号が安定するまで BAM 追跡プロファイルのビルドを遅延する
Web サービス公開ウィザードを使って公開された Web サービス	Web サービス発行ウィザードを使用して ASP.NET Web インターフェイスを生成すると、BizTalk Server アセンブリのアセンブリ バージョンが ASP.NET ソース コードに含まれます。 アセンブリのバージョン番号は、Web サービス操作の bodyTypeAssemblyQualifiedName プロパティの一部として、ASP.NET インターフェイスによって実行時に使用されます。 bodyTypeAssemblyQualifiedName プロパティを更新せずにBizTalk Server アセンブリのバージョン番号が変更された場合、後続の Web サービス操作はBizTalk Serverによって拒否されます。 受信場所で XmlDefaultPipeline を使用する場合、サブスクリプションはドキュメントの種類に依存します。 サブスクリプションでは埋め込みアセンブリ情報が使用され、アセンブリが存在しない場合は失敗します。 PassThruPipeline を使用する場合、サブスクリプションではこの埋め込みアセンブリ情報が無視されます。PassThruPipeline は、ポートを公開し、ウィザードで受信場所を作成する場合の既定のパイプラインです。