問題タブ [out-of-process]

明らかな理由なしにセッションがリセットされるという非常に特殊な問題に直面しています。これはランダムに発生し、数十または数百のリクエストごとに1回発生します。

私のWebアプリケーションは、Windows 2003、IIS 6.0、.NET1.1で実行されています。アプリケーションには、Page_Loadイベント中に一連のSession変数を設定するWebページがあります。データは、ASPNETStateServiceにアウトプロセスで保存されます。

Page_loadイベントが終了し、ページが表示された後、ユーザーはボタンをクリックします。ボタンをクリックすると、セッションデータが取得され、操作が行われます。そして、このButton_clickは、問題が発生する場所です。場合によっては、セッション変数がnullになり、nullRefExceptionが発生します。

トレースは、Button_clickイベント中のsessionIDが、Page_Loadイベントのセッションとは異なるIDを持つまったく新しいセッションであることを示しています。したがって、アプリケーションは、Page_Load中に保存されたデータの取得に失敗します。イベントログは、問題のあるリクエストのセッション変数が実際にPage_loadイベント中に入力され、応答が問題なく送信されることを示しています。これにより、通常はデータが保持されます。

セッションのタイムアウトを除外しました。タイムアウトすると同じnullRefExceptionが発生しますが、Page_loadからの同じセッションIDを使用して、存在しないデータを取得します。この場合、sessionIDは元のIDとは異なります。

ASPNET Cookieをいじったり、session.abandonを使用したり、セッションから誤ってアイテムを削除したりすることはありません。

私の質問は、どのサーバー側の要因がカード所有者のセッションをそのようにリセットさせる可能性があるかということです。アプリケーションイベントログには、有用な情報は含まれていません。

また、ページの後続のポストバック時にIISに新しいセッションを割り当てるように強制する可能性のあるクライアント側（Cookieの改ざんなど）はありますか？

よろしくお願いします。

スレッドの非安全性を回避するために、COM プロセス外オブジェクトにラップしたいシングル スレッド ライブラリ (スレッド セーフではない) を扱っています。新しい各 COM オブジェクトが独自のプロセスでインスタンス化される動作が必要です。これは、何らかの形式のアウトプロセス シングルトンです。

私がハードコア COM を扱ってからしばらく経っているので、これにどのようにアプローチすればよいのか、またはトリックなしでこれがまったく可能かどうかはわかりません。

COM経由で存在するプロセスとは別のプロセスからC＃オブジェクトにアクセスしようとしています。C＃オブジェクトはCOMに公開されます。

問題は、これらのオブジェクトでメソッドを呼び出すと、これらの呼び出しの副作用を発生させたいoutproc COMサーバーではなく、ローカルで呼び出しが実行されることです。

より正確には、outprocCOMサーバーにあるオブジェクトにアクセスしようとするプロセスで私が行うことは次のとおりです。

次に、結果をIMyInterfaceC＃クラスの適切なインターフェイス（）にキャストし、そのインターフェイスのメソッドを呼び出すと、期待どおりにoutprocCOMサーバーでリモートで実行されます。

このインターフェイスを使用して他のC＃オブジェクトを取得すると、問題が発生します（をIMyInterface.GetOtherObject()返すメソッドを使用しますIOtherObjectInterface）。

で呼び出しを行うとIOtherObjectInterface、outproc COMサーバーではなくローカルで実行されるため、副作用が失われます（たとえば、SetValueメソッドを呼び出すと、値がoutprocサーバーに到着せず、失われます）。

さらに、実行時にデバッガーを確認すると、リモート呼び出しが機能System._ComObjectするインターフェイスのタイプが実際のタイプ（IOtherObjectInterface）であるのに対し、リモート呼び出しが機能しないインターフェイスのタイプは実際のタイプであることがわかります。

私はIMyInterface（リモート呼び出しが機能するもの）がCOMに公開される方法（IOtherObjectInterfaceリモート呼び出しが機能しないもの）についてすべて（実装されているすべての属性と他のインターフェイス）を複製しようとしましたが、運がありません。

私が行うIOtherObjectInterface呼び出しが、誰にも使用されないローカルプロセス（呼び出しが発行されるプロセス）ではなく、RPCを介してoutprocサーバーで実行されるようにするにはどうすればよいですか？

編集：

それ以来、機能しないオブジェクト（IOtherObjectInterface）を、機能するオブジェクトに使用するのと同じメソッド（oType.InvokeMember（ "GetOtherObjForMyClassMethod"、....））を使用して取得した場合でも、それが機能することがわかりました。動作しません（オブジェクトに対して行った呼び出しは、まだoutproc COMサーバーに転送されません）。

したがって、問題はクラス自体にあり、オブジェクトの取得に使用されるメソッドにはありません。

両方のクラス（機能しているクラスと機能していないクラス）が同じ方法でシリアル化を実装しているように見えても、この問題は何らかの形でシリアル化に関連していると強く思います...

EDIT2：

私が得られない部分は、この「COMリモーティング」が機能するクラス（COMサーバーの外部でオブジェクトを取得するときにSystem._ComObjectを取得するクラス）が属性「serializable」を持っているという事実です。この属性を持つタイプのデフォルトは、値によるマーシャルだと思いました。

COMインターフェイスを既存のアプリケーションに追加するつもりです（ちなみに、これはWin32を使用してC ++で記述されています）。COMオブジェクトの使用経験があるので、インターフェイスなどの基本的なCOMの概念は知っていますが、実際にコンポーネントを実装するのはこれが初めてです。

最終的には、COMインターフェイスを使用して、VBなどのスクリプトからアプリケーションを自動化できるようにしたいと考えています。私は2つのステップがあることを理解しています：

1. アプリケーションはアウトプロセスサーバーとして機能する必要があります（つまり、MIDLを使用して、プロキシDLLとスタブDLLのコードを生成する必要があります）。
2. サーバーを入手したら、IDispatchインターフェイスを実装することで自動化機能を追加できます。

MIDLを使用するServer-in-an-EXEの機能とそうでないものはすでに少し急勾配であるため、IDispatchに進む前に、まずそれらすべてを把握したいと思いました。

DaleRogersonの「InsideCOM」という本を読んでいて、EXEのサーバーに関する章を完了しました（次の章では自動化について説明します）。

「EXE内のサーバー」の章では、サーバーとクライアントを実装するサンプルコードを提供します。ただし、サーバーを手動で起動する必要があります。これは私を混乱させます。明らかに、私のアプリケーション（=サーバー）がクライアントプロセスによって使用されている場合、この追加の手動手順は必要ありません。サーバーを自動的に起動するメカニズムはありませんか？それとも、それを達成するために自動化が必要ですか？現時点では、サーバーを手動で起動しなければならない可能性があるため（サーバーが1つでもある場合）、正しい方向に進んでいるのではないかと疑っています。

うまくいけば、これについてもっと知識のある人が、私が見逃している情報を見て、正しい方向に私を向けることができます。

私は、最初のアウトプロセス COM サーバーを実装している最中です (つまり、最初の COM サーバーです)。IDL ファイルを作成し、プロキシ/スタブ DLL のコードを生成し、DLL をコンパイルして登録する手順に従いました。

レジストリキーを確認すると、

• という名前のキーでHKEY_CLASSES_ROOT/Interface/<GUID>、その値は (たとえば)IMyAppであり、
• という名前のキーでHKEY_CLASSES_ROOT/Interface/<GUID>/ProxyStubClsid32、その値は です<GUID>。つまり、キー名と同じ値です。

2番目のキーの値がキー名と同じ値になる方法がわかりません<GUID>。現在の理解では

• ではHKEY_CLASSES_ROOT/Interface/<GUID>、GUID はインターフェイスIDです。
• の値はProxyStubClsid32インターフェース ID ではなく、上記のインターフェースを実装するコンポーネントを参照するクラスID です
• HKEY_CLASSES_ROOT/CLSID/<GUID>/InprocServer32(GUID は上記のクラスID)の値は、プロキシ DLL を指します。

HKEY_CLASSES_ROOT/Interface/<GUID>/ProxyStubClsid32では、1 つがインターフェイス ID で、もう 1 つがクラス ID である場合、どのようにして の値が同じ値の GUID を保持できるでしょうか?

編集：私はまだこれに対する答えを望んでいます。簡単に言うと、コンポーネントとインターフェースは 2 つの異なるものなので、同じ ID を両方に使用するにはどうすればよいでしょうか?

私はアウトプロセスCOMサーバーを実装する方法を学び、このコードプロジェクトの記事「ローカルCOMサーバーとクライアントの構築：ステップバイステップの例」に出くわしました。

ビルドでき、正常に動作しますが、プロキシ/スタブDLLはどこにありますか？私が見ることができるのは、ビルド中にプロキシ/スタブコードが生成されるIDLファイルだけです。しかし、DLLはどのように構築され、どこにありますか？

ローカルCOMサーバーを共通のアカウントで実行するにはどうすればよいですか（ローカルシステムが適しています）。RunAsのドキュメントは、DCOM専用のようで、ローカルでは機能しません。

私が直面している問題は、CoCreateInstanceが異なるデスクトップで実行されているプロセスから呼び出されており、このシナリオのSCMがデスクトップごとに新しいサーバーを起動したいということです。設計どおり、単一のインスタンスのみが必要です。

COM サーバー (ATL で実装された COM クラス) を持つ exe を含むコードを実行しています。すべてのインターフェイスが定義された .idl ファイルがあります。COMサーバーの登録後、レジストリエントリを調べたところ、次のことがわかりました。各インターフェイスには、IID と ProxyStubClsid32 を持つエントリがあります。私が言及したCOMサーバーによって実装される1つのインターフェイスがあり、キーフィールドにIID = ProxyStubClsid32の値があり、他のすべてのインターフェイスインターフェイスエントリのProxyStubClsid32フィールドに同じIIDエントリがあります。なぜこれがそうですか??

次に、このインターフェイスを実装する新しいインターフェイスと新しい COM コンポーネントを exe に追加して登録しようとすると、レジストリで観察できることは、この新しいインターフェイスの IID エントリとその ProxyStubClsid32 が同じであることがわかりました。また、新しく追加された IID は、他のすべてのインターフェイスの ProxyStubClsid32 に存在します。

ProxyStubClsid32 には何が入りますか? これはどのように決定されますか?

新しいインターフェイスを追加した後でも、以前の IID が ProxyStubClsid32 に存在するようにします。これどうやってするの ？？

また、コンポーネントをロードするシェル拡張機能を実装しているため、explorer.exe はこのレジストリ エントリをキャッシュしますか。古いエントリを参照していると思われるため、その exe で新しいインターフェイスを照会しても機能しません。explorer.exe を再起動すると、すべて正常に動作します。

誰でもこれについてコメントできますか。

これに対する答えには、私の問題に対するいくつかのヒントがあるようです:アウトプロセス COM サーバーのレジストリ キー

前もって感謝します。

activate イベントが発生するたびに、プロセス外の COM オブジェクトから文字列を要求する VB.NET Windows フォーム アプリを作成しました。私のフォームには 2 つのタブがあるため、ウィンドウがフォーカスされるたびにプログラムで正しいタブに切り替える必要があります。までは正常に動作します...

偶然、誰かが以下を含む vbscript (はい、exe ではなくスクリプト) を実行しました。

このスクリプトは常にアプリをクラッシュさせます。通常、非常にひどいため、例外ダイアログは通常、それ自体を描画できません。タスクマネージャーから強制終了する必要があります。場合によっては、例外が読み取り可能です。（Visual Studioで実行中のexeにアタッチして例外を確認しました）。「System.Runtime.InteropServices.COMException (0x8001010D): アプリケーションが入力同期呼び出しをディスパッチしているため、発信呼び出しを行うことができません。」

私の心を本当に混乱させているのは、私のアプリにはミューテックスを使用した複数のインスタンス検出があり、既存のインスタンスが実行されている場合、私自身のコード (コンパイル済み) は VB.NET 独自の AppActivate キーワードを使用し、これは私のアプリをクラッシュさせません。実行中のインスタンスをアクティブ化し、期待どおりに冗長インスタンスを終了します。

この問題は、cscript/wscript の AppActivate によってのみ引き起こされるようです。これを確認するために、3 ライナーの .vbs を作成しました。繰り返し可能です。

コンパイルしたアプリでこれをトラップまたは回避する方法はありますか?