1

Windows 2003 Server または 2000 を使用して、別のシステムで使用する COM+ アプリケーション プロキシを生成すると、エクスポート中に作成される MSI パッケージ内に .NET Enterprise Services コンポーネントが含まれます。.NET コンポーネントも GAC に登録され、アプリケーション プロキシのインストール中に regsvcs が自動的に実行されます。

ただし、Windows Server 2008 にはアセンブリが含まれていないことがわかりました。.tlb は含まれますが、.dll は含まれず、GAC にもインストールされません。もちろん、アプリケーションがアセンブリを見つけることができないと、すべてが失敗します。

2000 年から 2003 年までの動作が確実に機能するようにするために何をすべきか知っている人はいますか?

更新.NET アセンブリだけでプロキシを生成でき、正常に動作しますが、他のアセンブリまたはレガシー VB6 COM+ dll を同じパッケージに追加しようとすると、別のプロセッサ用にビルドされたと表示されます。

更新任意の CPU モード (すべてのプロジェクトが設定されている) でビルドする場合、アセンブリをコンポーネント サービス アプリケーションにドロップして登録すると、既存の 64 ビット アプリケーションの場合は 64 ビットが使用されることを理解しています。ただし、これは 32 ビット アプリケーションです。COM+ アプリケーションに登録されている 32 ビットの VB6 dll があります。そのため、32 ビットのレジストリなどを使用する必要があり、アプリケーションが 32 ビットになります。そのため、後で .NET Any CPU アセンブリを追加すると、それは 32 ビットである必要があります ... ただし、アプリケーションをエクスポートすると、.NET アセンブリは、作成された .MSI に追加されません。

更新32 ビットの ServicedComponents をエクスポートできないというバグについて説明しているhttp://support.microsoft.com/kb/924729を見つけました ... 修正プログラムがありますが、これは Windows Server 2003 用です。問題を絞り込みました正しくエクスポートされていないのは 32 ビットの ServicedComponents だけです。

4

3 に答える 3

3

任意の cpu にコンパイルされた .NET dll は、jit コンパイル時にビット数を取得します。COM+はハードなビット感しかありません。x86 または x64 ですが、ニュートラルではありません。このため、任意の CPU ではなく、2 つのうちの 1 つを使用する必要があります。

伯爵

于 2010-11-10T02:04:00.203 に答える
2

MS には、2008r2 のこの問題に対するホットフィックスがあります。バグであることを確認してもらい、昨年修正プログラムをリリースすることができました。それらに連絡して HF を取得してみてください。

于 2012-02-07T16:17:11.493 に答える
1

この件について、マイクロソフトのテクニカル サポートと連絡を取り合っています。問題は、レジストリとカタログが変更されたため、COM+ アプリケーションから 32 ビット ServicedComponent を Windows 2008 64 ビットで正しくエクスポートできないことです。これは Windows Server 2003 でも問題でしたが、修正プログラムによって修正され、Windows Server 2008 64 ビットで修正済みとマークされていましたが、実際には 2008 では修正されませんでした。これは Windows 7 のバグでもあります。

この問題に関心のあるすべての Windows 7 開発者は、Microsoft テクニカル サポートに連絡して、この問題が発生していることを報告する必要があります。Microsoft は、顧客からの費用の正当化なしにこれを修正するつもりはないためです。私たちは、MS に私たちのビジネス ケースを正当な理由として受け入れてもらうよう努めているところです。何か変更があれば、今後この記事を更新します。

于 2010-01-28T16:07:42.703 に答える