問題タブ [appdomain]

現在のアプリケーション ドメインの AppDomain.CurrentDomain.SetupInformation.PrivateBinPath を変更できるかどうかは誰にもわかりませんか? または、これは将来の appdomain インスタンスにのみ影響します..

ありがとう。

シナリオ: Web 配置プロジェクトを使用して n 層エンタープライズ ASP.NET アプリケーションを配置しました。すべての層は、ASP.NET アプリケーションによって消費される独立したアセンブリを生成します。

問題:アプリを実行すると。展開後初めて、依存アセンブリをメモリにロードするのに多くの時間がかかります。しかし、一度その照明高速アプリをロードしました。アプリにアクセスしているユーザーがいない場合、IIS はアセンブリをメモリからアンロードし、ユーザーが後のインスタンスでアプリにアクセスしようとすると、すべてのアセンブリを再度ロードし、ロードするのに同じ時間がかかります。初めてそうする必要があります。

メモリ常駐に対するアセンブリの揮発性をオーバーライドして、アセンブリをメモリに永続的にロードし続けることができるソリューションを探しています。

または、ユーザーが上記の問題を解決するアプリを喜んで使用できるようにするその他のソリューション。

アプリケーションが起動するたびにすべてのタイプのすべてのプラグイン アセンブリを検索することを避けるために、タイプ キャッシュ システムが配置されていますが、.NET 1.1 から 2.0+ に移行すると、イベント ログに致命的な実行エンジン エラー (6B3979C6) が記録されます ( 80131506) AppDomain.Load() で

1. AppDomain が AppDomain.CurrentDomain でない場合に限ります。2. アセンブリが実行可能ファイルのディレクトリにありません。

ユーザーがプロジェクト固有のディレクトリに独自のアセンブリを提供できるようにするため、2. を回避することはできません。

1. が必要なので、型をスキミングした後に AppDomain をアンロードできます。

私はこのコードの所有者ではありませんが、十分な情報を提供していない場合は、適切な質問をすることができます。

このコードにより、キャッチできないエラーが発生します。

.NETアーキテクチャがアプリケーションドメインの概念を導入したことは誰もが知っています。ASP.NETは、Webサーバー上で実行されるWebアプリケーションごとにアプリケーションドメインを作成します。プロセスビューアでは、新しいプロセスが作成されていないため、実行中の個々のWebアプリケーションのプロセスは表示されません。

次のような個々のWebアプリケーションの統計を表示するにはどうすればよいですか。

• CPU使用率、
• メモリ使用量およびプロセスビューアを使用して通常表示できるその他の統計情報はありますか？

アプリケーションと外部サービス間の接続を管理するサーバー アプリケーションでコンポーネントを構築しています。私のコンポーネントは、サーバーが利用できないことを検出し、サービスが利用可能になるまでバックグラウンド スレッドを開始してから、「動作中」状態に再び入ります。

私の問題は、このスレッドの実行中にコンポーネントを呼び出すプロセスが終了すると、スレッドが終了するまでアプリケーションが終了しないことです。基本的に、このサービスが利用可能な場合、私のアプリケーションはシャットダウンできません。

私の質問: バックグラウンド スレッドが終了できるように、アプリケーションが閉じようとしているかどうかを検出する方法はありますか? AppDomain クラスでいくつかのイベントに気付きましたが、どの条件とどの環境でそれらが発生するかはわかりません。

これは低レベルのコンポーネントであるため、実行中の環境について何も知られたくありません。また、高レベルのコンポーネントからシャットダウン中であることを伝える必要もありません。

このコンポーネントは、WCF サービスと Windows サービス アプリケーションの両方で使用され、WinForm クライアント アプリからのテストも行っています。

同じクラス ライブラリを参照する 2 つの実行可能ファイルがあります。クラス ライブラリには、静的変数があります。その静的変数は、2 つの異なる実行可能ファイルでどのように保持されるのでしょうか?

これはどのように見えるかです：

アプリ 1:

アプリ 2:

私は、WCFおよびNetTCPサービスを利用するエンタープライズレベルのアプリケーションを作成中です。私は最初は好奇心からNetTCPを選択しましたが、データ処理の量が多いために結果を返すのに5時間以上かかると呼ばれるサービスを利用できるため、後でそれが最善の選択肢であると判断しました。

私が現在サービスを生み出す方法は、複数のステップからなるプロセスです。いくつかのデフォルトのもの（ポート番号、接続しているクライアントのサーバー名、HTTPとNetTCPを有効にするかどうかなど）を指定し、その下に「サービス」のコレクションがある構成ピース（System.Configurationを使用）がありますそれ。たとえば、基本的なものは次のようになります。

基本的に、ここで起こっていることは、私のWindowsサービスが開始され、<services />コレクション内のすべてを調べて、サービスごとにスレッドを生成し、起動時間を短縮します。各スレッドには、サービスが実際に存在するAppDomainが含まれているため、サービスに何らかの種類がある場合障害が発生しても、システムはダウンしません。

私が直面している「問題」は、このアプリケーションが約20のサービスをホストしており、すべてのサービスが稼働するまでに15〜20秒かかることです。スレッド化とAppDomainの部分を実行して、その値に下げました（各サービスが順番に開かれるため、1分以上かかりました）が、実際にははるかに高速になる可能性があります。

誰か提案がありますか？Google Bingには、1つのサービスをホストするための例がたくさんありますが、実際のアプリケーションについてはあまりわかりません（残念ながら、「HelloWorld」はエンドユーザーにとって魅力的ではありません）。現在、WindowsサービスとNetTCPを介して複数のサービスをホストしている場合、どのように行っていますか？

構成ファイルを読み取るアセンブリ (DLL) をロードしています。構成ファイルを変更してから、アセンブリを再ロードする必要があります。アセンブリを 2 回目にロードした後、構成に変更がないことがわかります。ここで何が悪いのか誰にもわかりますか？構成ファイルの読み取りの詳細は省きました。

.net では、新しい AppDomain 内にアドインを作成できます。新しい AppDomain の作成は新しいことではなく、AppDomainSetup クラスを使用して、新しく作成された AppDomain のすべてのスタートアップ パラメーター (app.config の場所など) を指定できます。ただし、新しい AddInProcess (完全に新しいプロセス内で AddIn をインスタンス化する必要があることを指定) を使用して AddInToken をアクティブ化する場合、新しいプロセス内で AppDomain を作成するために使用される AppDomainSetup パラメーターに直接アクセスすることはできません。

これを行う方法はありますか?? 新しいアドインに、新しい app.config 設定や、AppDomain のさまざまなカスタマイズを強制的に使用できるようにする必要があります。

ここで助けてくれてありがとう...

App-Code フォルダーがどのように動作するかをよりよく理解しようとしています。特に、App-Code フォルダー内の新しいクラスが現在の AppDomain にどのように含まれているかについて興味があります。CodeDom で新しいオブジェクトをコンパイルするときと同じ方法で、2 つ目の一時的な AppDomain が作成されますか?

多くの点で、新しいクラス/オブジェクトを Web アプリケーションに移動する機能は非常に魅力的です。Rob Connery のMVC Storefrontは良い例です。App-code フォルダーを使用して新しい機能をデプロイした場合、考慮すべきトレードオフや落とし穴はありますか?

アップデート：

CoDe Magazineで、次の興味深い一節を含む記事を見つけました。

アプリケーション固有のコードは、ASPX ページまたはコントロールのインラインに配置したり、CodeBeside 部分クラスに配置したり、APP_CODE フォルダーに完全に自律的なクラスを作成したりできます。APP_CODE フォルダーは、ASP.NET 2.0 プロジェクトの特別なフォルダーであり、Web プロジェクトの非ページまたはコントロール関連のソース コードは、このフォルダーに入れる必要があります。ASP.NET は、APP_CODE のコンテンツをライブラリ プロジェクトのように扱い、そのコンテンツを別のアセンブリにコンパイルします。このアセンブリは、APP_CODE で定義されたクラスのいずれかを使用する ASPX/ASCX ページから ASP.NET が作成するすべてのページまたはディレクトリ レベルのアセンブリによって参照されます。

私の質問はまだ残っています - このライブラリをサポートする 2 番目の AppDomain が作成されていますか? もしそうなら、パフォーマンスへの影響は最小限ですか?