問題タブ [com+]

COM オブジェクトを WCF でホストすることはできますか? それらをコンポーネント サービスから移動したいと考えています。どんなアドバイスでも役に立ちます

デフォルトでは、C# の構造体は、基本的に、これらのタイプのオブジェクトは COM 相互運用に一般的に使用され、それらのフィールドは定義された順序のままである必要があるという理由で実装されてい[StructLayout( LayoutKind.Sequential )]ます。クラスがLayoutKind.Auto定義されています。

私の質問は、構造体を明示的に指定する必要が[StructLayout( LayoutKind.Auto )]あります。これにより、デフォルトよりも利点が得られますか? つまり、構造体がstackで初期化されている場合、違いはありますか?つまり、GCは構造体を移動する必要はありませんか? また、構造体がヒープ上で初期化されている場合、つまりクラスの一部である場合に役立ちますか?

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 だけです。

VB6から使用することを目的としたサードパーティのCOM+DLLに問題があり、ハードウェアイベントのコールバックを設定する機能があります。ただし、私はVB.NETを使用しており、AddressOfは整数型ではなく参照型を返すようになりました。これは、COM+DLLのsetCallback関数を使用できないことを意味します。

この問題を回避する方法はありますか（ある種のラッパーを開発するために利用できるVB6がありません）、またはこれを機能させるために別のサードパーティのDLLを見つける必要がありますか？参考までに、Logitech G15（v2）キーボードのLCDにアクセスしようとしています。

参考までに、setCallback関数とコールバックのプロトタイプ自体を次に示します。

複数の Web サイトを実行している IIS 6 Web サーバーがあります。ある Web サイトには、以下の単純な構文を使用してアプリケーション変数を設定する ASP.NET コードがあります。

同じサーバー上の別の Web サイトは、設定された値を読み取ることができますか?

COM+ アプリケーションはその値を読み取ることができますか?

私は、 Jacobまたは Java-COM Bridge を使用して MS VBA および MS Word の COM インターフェイスを介して呼び出しを行う従来の Java アプリケーションを維持しています。私はSun のcom4jを見てきましたが、有望に見えます。

私には良いように見える理由は、IDispatch ではなく、メソッドへの vtable バインディングを使用しているためです。操作するすべての COM オブジェクトに vtable インターフェイスが存在すると仮定すると、IDispatch の代わりにそれらを使用する方がクリーンに見えます。COM と CORBA がホット バイナリ インターフェイス テクノロジを使用していた時代にさかのぼると、vtable を介した早期バインディングは、IDispatch を介した遅延バインディングよりも優れたパフォーマンスを発揮したことを覚えているようです。

Jacob から com4j に移行した人はいますか? もしそうなら、落とし穴と学んだ教訓は何でしたか?

サード パーティから入手した Visual Studio アドインの代替を作成しています。彼らのアドインには 1 つの機能がありますが、これを置き換えるのに苦労しています。それは、彼らの別のプログラム (まだ必要) を起動して、Visual Studio の PID を伝え、他のプログラムが COM+ 経由で Visual Studio アドインをコールバックできるようにすることで、彼らの別のプログラムとやり取りします。

アドインと他のアプリの間の会話をリバース エンジニアリングするにはどうすればよいでしょうか。私はサード パーティのアドイン/アプリのソースを持っていませんが、私がしていることを行う法的権利は持っているので、リバース エンジニアリングは問題になりません。

regasmツールを介して登録した場合、COM +コンポーネントはどのアカウントで実行されますか？アカウントを識別するためのregasmのコマンドパラメータに気づきませんでした。regasmを実行するには管理者権限が必要ですが、COM +コンポーネントも管理者権限で実行されると思いますか？

プログラムで COM+ サービスを構成することは可能ですか。

C#または任意のスクリプトを使用して次のことを行う必要があります

1. [管理ツール] -> [コンポーネント サービス] を開きます
2. [コンポーネント サービス] -> [マイ コンピュータ] -> [COM+ アプリケーション] を展開します。
3. HyperV Environment Manager (COM+ サービス名) を右クリックし、[プロパティ] を選択します。
4. [プーリングとリサイクル] タブをクリックします。
5. [アプリケーションのリサイクル] で、[メモリ制限 (KB)] の値を 262144 に設定します。
6. [OK] をクリックします。
7. HyperV Environment Manager (COM+ サービス名) を右クリックし、[シャットダウン] を選択します。
8. HyperV Environment Manager (COM+ サービス名) を右クリックし、[開始] を選択します。

ガイドしていただけるか、コード スニペットを送っていただければ幸いです。

前もって感謝します。

よろしく、 Sreejith Rajan

私は Wix を初めて使用し、明らかに自分では解決できない問題に遭遇しました。

簡単な背景: 私は、大企業に展開するための SOA ベースのアプリケーションの包括的なスイートを構築しているソフトウェア ベンダーを代表しています。私たちのアーキテクチャは、個別にインストール/アップグレードできる多くのレイヤーで構成されているため、ゼロから構成するいくつかのインストーラーを作成しています (プラットフォーム、コア フレームワーク コンポーネント、サービス レイヤー、ビジネス レイヤー、アプリケーション レイヤーなど)。

ソフトウェア バージョン:
-Wix 3.5.1309.0 (wix.dll)
- Visual Studio 2008、.Net 3.5
- ビルド OS: Windows 2008 R2 Standard 64 ビット
- デプロイ OS: Windows 2008 Standard 32 ビット

私の問題は、COM+ アプリケーションに .Net アセンブリをインストールすることに関するものです。「タイプ ライブラリをインストールできませんでした」というエラーが表示され続けます。私は見つけることができるすべてのドキュメントを読んでおり、数日間グーグルで検索しています。このトピックに関する投稿がかなりありますが、まだ問題を解決できません。

問題を切り分けるために、問題を別のインストーラーに抽出しました。まず、メイン インストーラーを実行し
ます。 1. COM+ にインストールするアセンブリを含め、すべてのアセンブリを GAC にインストールします。
2. ローカル ユーザーとグループを作成します。
3. ロールなどを含むターゲット COM+ アプリケーションを作成します。
4. ターゲット アセンブリとコンパニオン タイプ ライブラリをフォルダーにインストールします (GAC ルックアップの問題を解決するため)。

このインストーラーは、インストール/修復/アンインストールできます。すべて正常に動作します。

次に、問題のみを含む最小限のインストーラーを実行して、次のことを試み
ます。 1. プレインストールされた .dll と .tlb を参照して、既存の COM+ アプリケーション (サーバー) にアセンブリをインストールします。

インストールが失敗し、ログに次のように表示されます。

また、COM+ アプリケーションはこのインストーラーによって作成されたものではありませんが、ロールバックによって削除されることにも気付きました。
サーバー マネージャーを使用して、インストーラーが参照している同じ物理ファイルからアセンブリを手動でインストールできます。コンポーネントを COM+ アプリケーションから手動で削除すると、インストーラーが機能します。

また、そもそも typelib を指定する必要があるのはなぜですか? とにかく、EnterpriseServices.RegistrationHelper はその場で typelib を生成しています。

これは、失敗している最小限のテスト インストーラーです。

乾杯、-
ニルス