問題タブ [biztalk-deployment]

2 つのプロジェクト ソリューションがあります。1 つのプロジェクトにはスキーマと BizTalk オーケストレーションが含まれ、もう 1 つのプロジェクトにはオーケストレーションから参照されて実際の作業を行う DLL が含まれています (これは共有コードであるため、単純にプロジェクトに組み込むことはできません)。 BizTalk アセンブリ)。2 番目のアセンブリは BizTalk アセンブリからの参照として追加され、問題なくオーケストレーションから #2 のメソッドを参照できます。

ただし、VS -> BizTalk から展開すると、リソース アセンブリは取り込まれず、BizTalk アセンブリが展開されるだけです。オーケストレーションをトリガーしようとすると、参照されているアセンブリを読み込めないというエラーが表示されますが、それを GAC と BizTalk アプリの "リソース" リストに追加すると、問題なく動作します。

このアセンブリに、BizTalk アセンブリと共に展開する必要があるものとしてフラグを付けるにはどうすればよいですか? どこかで参照の設定が欠落しているだけですか?

WebサービスコールでBizTalkを試す

要求/応答は自分の開発マシンでは正常に機能していますが、テストでは機能していません...

MSIを展開テストサーバー（別の仮想）にエクスポートし、アプリケーション/インポートを使用してアプリケーションを作成し、テストして機能していないことを確認しました...

• イベントログを確認すると、「ファイルまたはアセンブリを読み込めませんでした」というXLANGエラーが表示されます。

• GACを確認しましたが、BizTalkアセンブリがありません...

• 手動で追加したので、うまくいくようでした

追加されたWebサービス参照は、デプロイメントの一部としてアセンブリをGACする必要があることを意味しますか？

そして、混乱させるために、実際のテストサーバーにデプロイしてみて、MSIをインポートし、DLLをGACに手動でコピーしました...イベントログのXLANGエラーで失敗します:-(

• ここで何が起こっているのか分かりますか？

アプリケーションをBizTalkサーバーに展開するときは、テストマシンに展開し、必要なすべてのリソースを追加してから、運用サーバーにインポートするMSIをエクスポートします（2つあります）。先日、本番サーバーに、各開発者のソースコードの場所のコピーのように見えるフォルダーが数十個あることに気付きました。

例えば：

• C：\ Development \ MyProject1
• C：\ Projects \ SomeProject
• C：\ Users \ Ryan \ My Documents \ Visual Studio Projects \ Another Project
• 他の多く

これらはすべてBizTalkに展開したプロジェクトであり、フォルダーにはソースコードは含まれていません。フォルダーには、DLLファイルを含む各BizTalkプロジェクトの「展開」フォルダーのみが含まれています。ただし、MSIパッケージがDLLファイルをGACに追加しているか、少なくともMSIインストールターゲットフォルダーに配置していると思いました（すべてのMSIファイルは "C：\ Biztalk \ ProjectName"にインストールされます）。

誰かがここで光を当てることができますか？これらの余分なコピーは安全に削除できますか？それにより、BizTalkアプリケーションのトラックが停止しますか？

BizTalkアプリケーションで問題が発生しました。それらを削除することはできませんが、同時にVisualStudioから最新のものを展開することもできません。私はBizTalk2009を使用しています。

Visual Studioに表示されているエラー：

参照されているBizTalkプロジェクトが他のプロセスで使用されているため、更新できません

ホストインスタンスとアプリケーションが停止状態になっています。GACからdllを削除しようとしましたが、役に立ちませんでした。

私はまだBizTalkとEDIを学んでいます。私が現在の会社で最初に始めたとき、私は前任者のコンピューターを継承したので、多くの構成がすでに整っていました。最近、新しいラップトップを入手し、新しい開発環境の構成がほぼ完了しました。ここに来る前に、開発環境をセットアップする方法についてのドキュメントはありませんでした（私はかなり長くなったそのようなドキュメントを作成しました）。

私が理解できない最後の部分は、EdiRecieveポートとSendEdiポートです。それらは私の古い開発環境にありますが、私の新しい環境には表示されません。Googleのゴミ箱のダイビングを確認できたところ、Microsoft.BizTalk.Edi.EdiPipelinesに存在しますが、デフォルトではインストールされていないようです。私の質問は、開発に使用するプライマリBizTalkアプリケーションでこれらを取得するにはどうすればよいですか？

もう1つの副業として、BizTalk EDIアプリケーションがあります。これは、デフォルトでインストールされているようで、私が探しているパイプラインがあります。そのアプリケーションまたは何かを何らかの方法で参照する必要がありますか？

dllをGACしてみ​​ましたが、うまくいかないようです。

私は現在、複数環境の BizTalk 展開を担当しており、高可用性とスケーラビリティを提供するために BizTalk グループに 2 つ以上の BizTalk Server を展開することを計画しています。

たとえば、SQL アダプターの場合、2 つの BizTalk 受信ホストが同じ DB テーブルでポーリングを続ける可能性があるためです。

当初、SQL に対する私の考えはロック ヒントを使用することでしたが、これに関して他に懸念があるかどうか、または他の実証済みの解決策があるかどうかはよくわかりません。

ファイル アダプターの場合私が知っていることは、処理中にファイルのファイル名を変更するように受信アダプターを設定して、他の BizTalk ホストがファイルを取得しないようにすることです。 .

ヘルプ/提案をいただければ幸いです。

どうもありがとう

開発チームのために Team Foundation Server 2008 にアップグレードする可能性を検討しています。私たちの主な理由の 1 つは、BizTalk 2009 を取り巻くいくつかの展開機能ですが、BizTalk 以外の他のプロジェクトにどのような利点があるのか​​、私は興味があります。

これまでのところ、ワンクリックのビルドとデプロイ プロセスへの移行、単体テストの追加、および継続的インテグレーションに関心があります。私が働いている会社にとって、いくつかの明確な前進があります。

これを上層部に提案する際に、他にどのようなメリットや情報を確認する必要がありますか? 私は技術的な理由を探しています。この議論ではお金はあまり重要ではありません。

BizTalk には多くの煩わしい展開/構築の問題があるという事実を気にしたことがある人はいますか?

たとえば、C# アセンブリ クラスを使用してビルド/デプロイすると、定期的に sgen.exe エラーが発生します。これらのエラーは、アセンブリから削除すると修正されますが、一部の依存関係が再び問題を引き起こしているため、再構築する必要があります。そうしないとアセンブリがトリガーされないため、Visual Studio を再起動します。はい、私は常に build event コマンドを使用します。

"C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" /i $(TargetFileName)

また、ビルド中に文字列やブール値などをシリアル化する際に多くの問題が発生しますが、これもビジュアル スタジオ ソリューションを再起動すると修正されます。

また、.msi ファイルをインポートする場合は、実行中のすべてのインスタンスを登録解除して削除し、適切にデプロイする必要があります。

ホスト インスタンスを再起動することも忘れないでください。これはビジュアル スタジオ プロジェクトのオプションですが、ほとんど機能しないため、ホスト インスタンスを手動で再起動することは日常的なことではありません。

率直に言って、参考文献の問題などのように増え続けていることは他にもたくさんあります。1 日仕事をした後、さらにいくつかのことを考えることができると確信しています。

これらの問題に関して、誰かがいくつかのトリックを持っていますか? 私は毎時間それらに遭遇するからです。他の人もこれらに遭遇し、おそらくこれらの問題のいくつかを解決したのではないかと思っていました.

一部のスキーマの展開に問題があります:

私は、schemaAを含むアセンブリA、アセンブリAを参照するスキーマBを含むアセンブリB、およびスキーマCを含み、アセンブリAを参照するアセンブリCを持っています。

assemblyA を正常に展開でき、BizTalk 管理者のスキーマで schemaA を確認できます。

assemblyB または assemblyC のいずれかを適切に展開し、BizTalk 管理で対応するスキーマを確認できます。

assemblyB が既に展開されているときに assemblyC を展開しようとすると、assemblyB がそのスキーマと共に BizTalk 管理画面から消えます (逆も同様です)。

B または C から assemblyA への参照を削除すると、3 つすべてを一緒に問題なく展開できます (ただし、実際にはその参照が必要です)。

私は何を間違っていますか？

複数の BizTalk 2006 アプリケーション サーバーがあり、それらのプロジェクトのバージョンの同期を維持することはほとんど不可能です。MSI パッケージを展開し、それらをインポートし、GAC 内のファイルを照合し、いくつかのレジストリの変更を展開するという面倒なプロセスです。1 つの手順を実行しなかった場合、または誰かが DLL の更新されたコピーを 1 つのサーバーに直接展開し、別のサーバーには展開しなかった場合、何もありません。簡単な言い方。

他の人は、2 つのサーバー間のソフトウェアのコピーが同じバージョンであることをどのように保証しますか?

背景:

私たちの環境には、2 つの (クラスター化されていない) BizTalk フロント エンド サーバーと、別のデータベース バックエンドがあります。最近まで、両方のフロントエンドを構成していましたが、トラブルシューティングのために 2 番目のサーバーでホスト インスタンスが停止していました。それらは数か月間無効になっており、その間にいくつかの更新されたコードを展開しています.

今朝、GAC のフォルダーと、デプロイされたプロジェクトの DLL のローカル ディスク コピーを保持するフォルダー (両方のサーバーの C:\OurProject\) でフォルダーの差分を作成しましたが、すべてが一致しました - 同じファイル サイズ、同じタイムスタンプ。しかし、2 番目のサービス セットをオンにすると、Server2 が古いバージョンのプロジェクト DLL を使用していることが明らかになりました。次に処理された 3 つのファイルのうち、2 つは正常な結果で、1 つは明らかに古くなっています。

動脈瘤を避けるのを手伝ってください。