特定の ConfigurationSection をロードしたいのですが、CLR がアセンブリをロードする方法に問題があります。
私の CustomConfigurationSection 定義は、基本的にアセンブリをロードし、リフレクションを介してそれに関する情報を発見し、それを「インストール」しようとする外部ツールを使用しているため、アセンブリのロードの全体的なプロセスでは見つけることができない特定のアセンブリにあります。Windows サービスをインストールしようとするときの installutil と非常によく似ています。
ConfigurationManager は、元のプロセスの場所で ConfigurationSection に必要なアセンブリを見つけようとするため、気が狂いそうになります。SysInternals Process Monitor を使用しているので、これは確かです。誰かが回避策や指示を提供できますか?
ありがとう！
アセンブリへのパスがわかっている場合は、ConfigurationManager.OpenExeConfiguration(exePath) を試してください。
私も同様の問題に直面しています。いくつかのDLLが動的にメインアプリケーションにロードされます。これらのdllのいくつかは構成ファイルを必要とし、私はそれを処理するためにデフォルトのConfigurationManagerを使用しています。（「.config」で後置されたdllの名前に基づいて）正しいファイルを正常に取得し、AppSettingsおよびConnectionStringsの設定を使用できます。
今、私はカスタム構成セクションをロードしようとしています。ランタイムは、セクションタイプがdllに見つからないことについて文句を言います。構成ファイル（configSectionsエントリ）で正しいdllを指定しましたが、そのdllは実際にはプラグイン自体であるため、dllがロードされていることがわかります。それでも; ランタイムはGAC/binディレクトリのタイプのみを使用して構成セクションを検索しているようです。
簡単に言うと、ロードしようとしているコードと同じdllで指定されているカスタム構成セクションをロードしようとしましたが、機能しません。
アセンブリ (構成セクションを定義する) が読み込まれる前に、構成セクションにアクセスしようとするのはなぜですか? 構成セクションを使用してアセンブリの場所を定義していますか? もしそうなら、あなたは循環参照をいじっています。
カスタム構成セクションを定義するコードは、非常に独立したものにすることができます。独自のアセンブリにすることができます。このコードを独自のアセンブリに分離し、GAC またはランタイム パスにインストールすることをお勧めします。カスタム構成セクションを読み取るために必要なコードを「ロード」するために外部ツールが必要な理由がわかりません。
カスタム構成セクションを逆シリアル化するためにアセンブリが必要であるにもかかわらず、CLR がアセンブリを見つけられない場合は、運が悪いと思います (または、問題を誤解していますか?)。
CLRにアセンブリを見つける方法はありますか(ヒントパスを提供する可能性があります)? そうでない場合は、app.config/web.config を使用する代わりに、このデータ用に別の XML ファイルを使用する方がよいでしょう。