問題タブ [settingsprovider]

.NETSystem.Configuration.SettingsProviderとApplicationSettingsBaseを使用して構成を処理するコードを見ています。

データベースをデータストアとして使用するSettingsProviderから派生したクラスがあり、次にApplicationSettingsBaseから継承し、[SettingsProvider（typeof（MySettingsProvider））]属性を持つ他の設定クラスがあります。

問題は、これらの設定クラスを複数のアプリケーションで使用していることですが、最初にロードされたときに、構成値を永続的にキャッシュしているように見えます。問題は、あるアプリケーションで設定が変更された場合、他のアプリケーションはどこにでもキャッシュされるため、次の再起動まで設定を取得しないことです。

私の質問は、SettingsProvider実装、またはApplicationSettingsBaseから派生したクラスに値をキャッシュせず、設定にアクセスするたびにデータストアを再クエリする方法はありますか？有効な答えは、これらのクラスがマルチアプリケーション環境での使用を意図していないということかもしれません...

設定ファイルに別の場所を指定する必要があります。何時間も検索した結果、独自の SettingsProvider を作成する必要があることがわかりました。コンストラクタで設定ファイルのパスを指定できるものを作成することに成功しました。プログラム的には、次のように構成できます。

var mycustomprovider = 新しい CustomSettingsProvider(パス);

私が抱えている問題は、カスタム プロバイダーを呼び出す方法がないことです。VS 2008 で生成された設定ファイルを次の属性で装飾できます。

ただし、この属性では、パスを使用してオブジェクトを構築することはできません。また、SettingsProvider をプログラムで設定して、実行時に任意のパスを渡して設定を保存できるようにしたいと考えています。私がネットで見た例では、SettingsProvider をプログラムで呼び出す方法について言及していません。

.NET アプリケーションでは、DB に保存するなど、特定の設定が必要な場合はLocalFileSettingsProvider、例のカスタム設定プロバイダーに置き換えることができます。

カスタム設定プロバイダーを作成してアプリケーション間で設定を共有する

カスタム設定プロバイダーの作成

特定のプロバイダーを使用する設定クラス ( を継承するクラス) を宣言するには、ApplicationSettingsBaseそれを装飾しSettingsProviderAttribute、プロバイダーの型をパラメーターとして渡します。[SettingsProvider(typeof(MyCustomProvider))]それ以外の場合は、既定値が使用されますLocalFileSettingsProvider。

私の質問:属性を使用せずに、アプリケーション全体でカスタム プロバイダーを強制的に使用するために使用できる構成またはトリックはありますか?

その理由は、MEF 経由でプラグインをロードしていて、プラグインがサード パーティ経由で作成されている可能性があり、設定の処理方法に関心を持たせたくないからです。

これまでは常にユーザー設定をレジストリに保存していましたが、ApplicationSettings. 表面的には非常に単純ですが、ネストされたグループを作成するのに問題があります。

ユーザーが現在アクティブな顧客に基づいて異なる必要があるいくつかの設定 (ユーザー スコープ内) があります。

たとえば、customerMr Bloggsをロードして の設定を にDefaultPriceすること12.34ができますが、customer を に変更しMr Smith、彼DefaultPriceは にする必要があります22.90。

カスタムを使用してみましSettingsProviderたが、顧客を変更したときに設定を更新できませんでした。使用しないことを検討しApplicationSettingsましたが、不足している簡単なものがある場合に車輪を再発明したくありません。

C#、.NET 4.0 Full、および Visual Studio 2010 を使用しています。 この問題を解決するにはどうすればよいですか?

この質問に従って、開発中のレガシー C# アプリでカスタム設定プロバイダーを正常に作成しました。SettingsProvider次の属性を介して参照されます。

しかし、今、私は別の問題に遭遇しました。

クライアント アプリには自動更新機能が含まれており、上記のクラスを含むクライアントの大部分が DLL (ここではclient.dllと呼びましょう) に組み込まれ、EXE によって使用されるように実装されています。EXE は最初に更新をチェックし、必要に応じて更新サーバーから最新の更新をダウンロードし、すべての DLL などを新しいバージョン ( client.dllを含む) に置き換えます。実行時に DLL を置き換えることができるようにするために、DLL に静的にリンクすることはできません。したがって、更新後、client.dllをロードして、次のように実行します。

これの残念な結果は、動的に読み込まれたアセンブリ内でフレームワークがカスタム設定プロバイダー クラスを見つけられないことです。LoadFrom上記の代わりに使用しようとしましLoadFileたが、役に立ちませんでした。私がこれまでに見つけた唯一の実用的な解決策は、フレームワークによって問題なく検出された実際の設定プロバイダーと同じ名前のローダー exe にプロキシ クラスを実装することです。次に、プロキシはクライアント アセンブリから実際の設定プロバイダーをインスタンス化し、すべての呼び出しを委任します。

これはうまくいくようですが、私はそれに満足していません。フレームワークが動的に読み込まれたアセンブリ内のクラスを直接見つけるのを助ける方法はありますか?

アップデート

私が得るエラーメッセージ：

デバッグとログ メッセージを介して、クラスの初期化メソッドが呼び出されないことが判明したため、クラスがインスタンス化されることはありません。つまり、上記の例外の背後に隠された初期化エラーはないようです。

もう 1 つ潜在的に重要なこと: クライアントは現在 .NET 2.0 で実行されており、近い将来にアップグレードする予定はありません。

更新 2

@jwddixonの回答で示唆されているように、AppDomainの調査を開始しました。最初に、Client.dll が実際に呼び出し元の EXE とは異なるアプリ ドメインに配置されているかどうかを確認する必要がありました。そのため、現在のアプリ ドメインにあるアセンブリを一覧表示したところ、Clientが実際にそこにあることがわかりました。しかし驚いたことに、実際にはリストにClientという名前のアセンブリが 2 つあることに気付きました。EXE と DLL のアセンブリ名は同じですが、バージョンが異なります (現在、EXE は 4.0.0.0、DLL は 4.0.1352.0)。 ）。私はこれまで十分に認識していませんでしたが、これは重要なことかもしれません。次にEXEアセンブリ名を変更してみます...

アップデート 3

...そして、それは実際に問題を解決しました! ああ...なぜだかわからないこのねじれたスキームを発明した私の未知の前任者に対して、私は現時点で非常に不快な考えを持っています...しかし、最終的に解決につながる質問とアイデアを提供してくれた皆さんに称賛を！

カスタム設定プロバイダーを実装しているときに、設定プロパティの値にアクセスすると、そのIsDirtyフラグが に変わることに気付きましたtrue。

PropertyValueReflector は、ゲッターがこのように動作する理由についての質問に対する答えを提供してくれます。次のようなステートメントが含まれています。

一見すると奇妙な振る舞いに、誰かが光を当てることができますか?

現在、アプリケーションのユーザー設定は、次のデフォルト ディレクトリに保存されています。

デフォルトの Microsoft 命名規則の意味を認識しています。私の質問は、実行時に、または appconfig ファイルを変更することによって、そのデフォルト フォルダーを変更するにはどうすればよいですか?

私の意図は、アプリケーションのユーザー設定が保存されるディレクトリのみを処理できるようにすることです。たとえば、ユーザー設定ファイルをこのディレクトリに保存したいと思います。

これが実現可能であることはわかっています。ユーザー構成ファイルをカスタム ローミング フォルダーに格納できる .NET アプリケーションを多く見てきましたが、そのフォルダーは、未処理のハッシュやその他の迷惑な命名規則を使用する Microsoft の既定の規則には従わないものです。