問題タブ [configurationsection]

キーと値のペアを app.config ファイルに保存できる構成セクションを作成する必要があります。キーと値のペアは、タイプに関係なく実行時に追加できます。値が元の型を保持することも重要です。次のインターフェースを拡張する必要があります

実行時には、次のように言えます。

System.Configuration.Configuration.AppSettings を試してみましたが、キーと値のペアを文字列配列に格納しているという問題があります。

必要なのは、System.Configuration.ConfigurationSection を実装することです。ここで、個々の設定をシリアル化する方法を制御できます。Visual Studio によって生成された設定がこれを行うことに気付きました。リフレクションを使用してすべての設定キーを作成しています。私が必要とするのは、このランタイムを動的に実行することです。

ConfigurationSection と ConfigurationElementCollection を使用して構成ファイルから読み取るクラスを作成しようとしていますが、苦労しています。

構成の例として:

特定の ConfigurationSection をロードしたいのですが、CLR がアセンブリをロードする方法に問題があります。

私の CustomConfigurationSection 定義は、基本的にアセンブリをロードし、リフレクションを介してそれに関する情報を発見し、それを「インストール」しようとする外部ツールを使用しているため、アセンブリのロードの全体的なプロセスでは見つけることができない特定のアセンブリにあります。Windows サービスをインストールしようとするときの installutil と非常によく似ています。

ConfigurationManager は、元のプロセスの場所で ConfigurationSection に必要なアセンブリを見つけようとするため、気が狂いそうになります。SysInternals Process Monitor を使用しているので、これは確かです。誰かが回避策や指示を提供できますか?

ありがとう！

.configファイルにいくつかのカスタム構成エントリがあります。すべてのロード/正常に動作します。提供されたデータをチェックする適切な方法があるかどうか疑問に思いました-いくつかのビジネスロジックを追加します。例えば...

ここで、各カスタムセクションのuniqueNameが一意であることを確認したいと思います。ConfigurationSectionを暗示するカスタムクラスの外でこれを手動で行う必要がありますか、それともそこで行うことができますか？（たとえば、設定ファイルなどを読み取った後のデリゲートのようなものですか？）

私は過去3日間ネットを精査してきましたが、この質問への参照が見つかりません。app.configで使用するカスタム構成クラスを作成しました。すべてが正常に動作します。この問題は、（構成要素の）構成プロパティが不要であり、app.configで定義されていない場合に発生します。構成プロパティにはデフォルト値が返されているようです。プロパティがapp.configで定義されていないかどうかを判断する方法を知っている人はいますか？（app.configを投稿しようとしていますが、その方法がわかりません...誰か知っていますか？）

カスタムの web.config セクションを取得して、Web サイトのサブフォルダーにあるアプリケーションの web.config に継承しようとしています。

カスタム セクションはメイン Web サイトで正常に動作しますが、カスタム セクションが継承されていないようです。

web.config の他の要素は継承されています。継承されていないのはこのカスタム セクションだけです。

これは設計によるものですか？カスタム セクションの継承を有効にする方法はありますか?

app.configファイルが複数の場所に分散されたさまざまな構成フラグメントから動的に構築される構成システムを作成しています。現在、システムは次のように機能します。

1. Bootstrapperは構成ファイルを作成します。
2. Bootstrapperは、新しい構成ファイルを構成ファイルとして使用して、新しいAppDomainを初期化します。
3. その結果、新しいAppDomainは新しい構成ファイルを使用するように構成され、すべて正常に機能します。

この複数のAppDomainアプローチから離れたいと思います。特にアンマネージライブラリやその他のレガシーコードに関しては、複雑さが増します。

1つのAppDomainに移動すると、ワークフローは次のように変更されます。

1. Bootstrapperは構成ファイルを作成します。
2. Bootstrapperは、構成ファイルを独自の構成ファイルにマージします。
3. Bootstrapperは、ConfigurationManagerキャッシュを更新します。
4. Bootstrapperは、同じAppDomainでメインアプリを起動します。

ConfigurationManagerはセクションをメモリにキャッシュしているようです。したがって、たとえば、手順3の前にAppSettingsを読んだ場合は、次のように呼び出す必要があります。ConfigurationManager.RefreshSection("appSettings");実際、ブートストラッパーによって使用されたセクションが更新されていることを確認する必要があります。

新しい構成ファイルのすべての構成セクションを繰り返し処理して強制的に更新することはできますが、これにより、構成マネージャーは構成ファイルで参照されているすべてのアセンブリを強制的にロードします。可能であればこれを延期したいと思います。ConfigurationManagerが現在メモリに持っているものを無効にする方法はありますか？

エントリ 'MyCustomElement' は既に追加されています。

私はこれに少し困惑しています。このコンソール アプリには、過去数週間でかなりの数のカスタム構成セクションが追加されましたが、問題はありませんでした。しばらくアプリを実行しましたが、つい最近 (過去 2 日以内)、この問題に遭遇しました。

3.5、仮想ディレクトリなどをインストールした後、古い Web アプリでこれが発生することについて読んだことがあります。ただし、ここでは常に 3.5 であり、これはコンソール アプリです。

最近発生した唯一の変更は、新しいカスタム構成セクションの追加です。エラーが発生したとき、当然そのセクションを削除しましたが、次の構成セクション (以前は機能していた) を原因としてエラーが返されました。