Microsoft がアプリケーション構成とランタイム データを処理するために推奨する方法は、一目で明らかなように思えます。App.config は、アプリケーション実行ディレクトリ (ほとんどの場合、C:\Program Files\ProductLocation) に格納され、特権ユーザーのみが書き込みアクセス権を持っています。 . （カジュアルなユーザーは重要なアプリケーション構成を変更できないはずなので、私には理にかなっています）。
通常のユーザー構成では、各ユーザーの個人用アプリケーション データ ディレクトリ (%APPDATA%) にコピーされる user.config があります。
しかし、これはいくつかの疑問につながります:
- 管理者としてプロセスを実行せずに、すべてのユーザーの構成を変更するにはどうすればよいですか?
- アプリケーションと共にデプロイされず、アプリケーションの初回起動時に生成されるアプリケーション データはどこに保存すればよいですか?
- データベースヘルスモニターアプリケーションのように、動的接続文字列をどのように持つことができますか?
プログラムデータのフォルダ(%PROGRAMDATA%→C:\ProgramData)を調べてみたのですが、ここは一般ユーザーには読み取り専用のようです。(Windows インストーラーは、必要に応じてここにフォルダーを作成しますが、それらはすべて読み取り専用です。) -> %ALLUSERS% はどうなりましたか?
Microsoft の方法が私の目に失敗する可能性がある例:
すべてのユーザーが自分の情報を同じデータベース (SqlCE ファイル db) に保存する必要がある金融アプリケーション。アプリケーションはユーザー権限で実行する必要があります (ウォレットを管理する管理者になりたくありません)。アプリケーションは、実行時に利用できず、EntityFramework を使用して最初の実行中に生成される可能性があるデータベースへの接続を必要とします。そのため、接続文字列でさえ動的である必要があり、そのような情報が固定されている app.settings で構成されていない可能性があります。
これはばかだ！ユーザーは、ファイル データベースに直接アクセスして、他のユーザーから機密情報を読み取ることができます。
-> セキュリティはファイルのアクセス許可だけでなく、データベース ユーザー、証明書、暗号化なども含まれる可能性があります。)
Microsoft が意図した方法の回避策として、独自の設定ハンドラーを開発する必要がありますか?
この質問はSOで何度も聞かれると思いますが、見つけたすべての回答は回避策、さまざまな解決策を示しました。「ベスト プラクティス」に関する質問はすぐに締め切られるので、ここで実際の例を示してみました。