2

共通のアプリケーション設定ファイルが必要であり、実行時にアプリケーションで編集できるようにする必要があります。

「ユーザー」はユーザーのローカルディレクトリに保存されるため、設定スコープに「ユーザー」を入れてビルドイン設定操作を使用したくありません。

一方、アプリケーション内からこのファイルに保存できないため、「アプリケーション」で.configを使用することはできません。

「独自の保存設定XMLファイルを簡単に作成できます」と言う人もいるかもしれません。そうかもしれませんが、MSビルドインクラスを使用した一般的な書き込み可能な構成ファイルの解決策は何でしょうか。

4

1 に答える 1

3

形式に関係なく、すべてのユーザーがデータを更新できるようにするには、すべてのユーザーがそのデータを保持するコンテナーに保存できる必要があります。

これは、テキスト ファイルから RDBMS まで、あらゆる形式に適用されます。

管理するファイル (例: .config(XML) ファイル) の問題は 2 つあります。

  1. 同時実行。
  2. アクセス制御。

およびConfigurationManager関連するクラスは.exe.config、構成要素とプロパティの適切な宣言を含むファイルに書き込みますが、基になるファイルは書き込み可能である必要があります。次のことを行う必要があります。

  1. インストーラーで ACL を設定して、すべての (該当する) ユーザーが書き込みアクセスできるようにします。これは、アプリケーションの外部でも同様に書き込むことができることを意味します。アプリケーションに基づいてアクセス制御を設定する機能がないため、これは避けられません。

  2. 外側に取り付けますProgram Files。UAC は書き込みを仮想化しますProgram Files(そのため、すべてのユーザーがどこにでも書き込めると想定しているアプリケーションは壊れません) が、これは共有の変更可能なデータには使用できないことも意味します。

並行性は別の問題です。2 人のユーザーが共有データを一緒に変更するのは何ですか? 変更時にロックとリロードを実装しない限り、1 人のユーザーが他の変更を上書きします。

代わりに、データにマルチユーザー データベースを使用することを検討してください。それらはこの種のことのために設計されていますが、構成ファイルはそうではありません。

更新（コメントに基づく）：

(管理者以外の) ユーザーが Program Files の a を更新しても.exe.config、UAC の仮想化にヒットします (つまり、すべての書き込みはユーザーごとの場所に送信され、他のユーザーには表示されません)。

メソッドを使用して、適切な ACL を持つ共有の場所 (例: in 1ConfigurationManager.OpenExeConfiguration(string) ) からをロードする方が簡単です。返されたオブジェクトには、 forおよび カスタム セクションからの暗黙的なロードのすべての機能に加えて、およびへのアクセスが含まれます。.configC:\ProgramDataConfiguration.exe.config<appSettings>SaveSaveAs

1もちろん、ハードコーディングではなく、正しい方法を使用して実際のローカル パスを取得します。

于 2012-11-12T17:32:42.340 に答える