1

いくつかのレベルの構成ファイルを使用する .Net 2.0 の Windows アプリケーションがあります。私の手に負えない理由により、アプリケーションは Windows アプリ (.exe) プロジェクトといくつかの DLL で構成され、それぞれに独自の app.config ファイルがあります。

（C＃で）を使用して、各DLLの構成ファイルを読み取る方法をうまく理解しました

ConfigurationManager.OpenMappedExeConfiguration("my DLL's config file path", ConfigurationUserLevel.None);

これは問題なく動作します。DLL の構成ファイル ("foo.dll.config") のファイル パス名を指定すると、このメソッドから構成オブジェクトを取得できることを確認できます。ただし、カスタム構成セクションにアクセスしようとすると、カスタム構成セクションのデータ型が見つからないという例外が発生します。

この方法で構成ファイルをロードするときに、コードで使用できる型情報を取得するには、他に何をする必要がありますか?

4

1 に答える 1

3

残念ながら真実です。これを処理する方法は、構成を.dll.configファイルからアプリケーションの構成ファイルにコピーすることです。唯一の例外は、Windowsフォームで使用される設定システムと関係があります。OpenMappedConfigurationはそれでうまくいくと思いますが、よくわかりません。

なぜ彼らがこれを.NET2.0で統合して問題を解決しなかったのか、私は知りませんでした。多分私は尋ねるべきです。

その日の早い段階で、MSDNのOsloフォーラム（ http://social.msdn.microsoft.com/Forums/en-US/oslo/thread/c93ee7f3-4f9b-4044）で、WCFに関連するこのような質問をしました。-b1f0-43ad72fb508d）。ブログの投稿やその他の回答を探していたときに（前述のように、「たぶん私は尋ねるべきです」）、フォーラムの投稿に対する回答が届きました。

簡単に言えば、答えは、オスロが問題を解決するのを待っていたため、.NET2.0ではこれを修正しなかったということです。

それを理解することで反対票を避けようとせずに、私はただ言及します：オスロはアプリケーションのモデルとアプリケーションコンポーネントが中央リポジトリに保存されることを奨励します。これには、インスタンスごとの構成のモデルが含まれます。理論では、このようなデータはすべて単一のリポジトリに保存されます（少なくともシステムごとに）。したがって、構成ファイルがどこにあるかという問題はもうありません。すべてが1か所にあります。構成セクションのメタデータを含むアセンブリを見つける必要はもうありません。メタデータは、構成データとともにリポジトリに保存されます。

明日私に聞いてください、そして私は違った感じをするかもしれません、しかし今、私はオスロの宗教を拾っているかもしれません...

于 2009-03-11T20:49:07.773 に答える