4

.Net Framework 3.5 以降を使用して Windows フォーム アプリを構築しています。ユーザー スコープでアプリケーション設定を使用して問題に直面しています。

ユーザー スコープのアプリケーション設定について初めて読んだとき、アプリケーションが設定をユーザーに関連付けることを理解しました。また、MSDN から、パスの下のuser.configファイルに設定が保持されることも知りました: %LOCALAPPDATA%\CompanyName\ProductName\ProductVersion フィールドApplication.LocalUserAppDataPath Reference: http://msdn によって返される値とまったく同じ値です。 microsoft.com/en-us/library/8eyb2ct1.aspx

ここでの問題は、MSDN に書かれているファイル パスに関する記述がすべて完全に間違っていることです。そして、実験では、ファイル パスが実際には%LOCALAPPDATA%\companyname\appdomainname_eid_hash\verisonであることを明確に示しています。

まず第一に、なぜこのような重要な情報が MSDN で間違っているのかについて、合理的な説明を知りたいと思っています。

第 2 に、ここでの問題は、.Net で展開メソッド (Windows インストーラーや ClickOnce など) を使用しておらず、使用するつもりもありませんし、使用したくもないことです。ここでは、リリースをビルドするだけで、リリースの exe ファイルをホスト コンピューターにコピーします。インストーラーを使用していないため、アセンブリ (exe ファイルなど) の場所を変更するたびに、.Net Framework はアセンブリを別のアプリケーションとして認識し、別のハッシュで新しいフォルダーを作成します。および新しい user.config ファイル。これはもちろん私にとって問題です。私が検討しているのは「ユーザー設定」ではなく「ユーザーとアセンブリの設定」であることを意味するため、論理的には私には適していません。ユーザーがアセンブリをどこにでも再配置でき、同じ設定ファイルにアクセスできる理由がわかりません (MSDN が誤って述べているように!!)

さらに、IsolatedStorage を使用して、まったく同じ問題に直面しています。また、IsolatedStorage では、アプリケーション設定の問題とまったく同じ理由で exe ファイルを再配置すると、アセンブリがある場所にあるときに保存するすべてのデータに完全にアクセスできなくなります。

どうすればこれを解決できますか、または少なくとも、ハッシュを使用した命名規則が.Netのどこから発生したかを知ることができますか?それに応じてexeの再配置を検討することを決定したときにMicrosoftが行った理由は何ですか??

4

1 に答える 1

1

MSDN のドキュメントが間違っている理由についての答えはありませんが、https: //msdn.microsoft.com/en-us/library にある .net 3.5 の正しいバージョンのドキュメントを確認する必要があります。 /8eyb2ct1(v=vs.90).aspx

また、ドキュメントによると：

設定ファイルの場所

app.exe.config ファイルと user.config ファイルの場所は、アプリケーションのインストール方法によって異なります。（私の強調を追加）

アプリケーション設定プロセスは、バイパスしている展開に密接に結合されています。クリック ワンスであっても、一部の展開戦略では、アプリケーションに応じて以前のバージョンの設定をプログラムで取得する必要があります ( https://msdn.microsoft.com/en-us/library/system.configuration.applicationsettingsbase.getpreviousversion(v=vs.90 .aspx )

更新があるたびに .exe を手動でコピーする必要がある場合は、独自のユーザー設定オブジェクトをローリングし、シリアル化を使用する方が適切でしょうか? 次に、ユーザー スコープの設定を共通のアプリケーション フォルダーなどの共通の場所に保存し、アプリケーションの起動時にユーザーに基づいてユーザー設定を逆シリアル化できます。

于 2015-04-16T19:52:53.050 に答える