アプリケーションのアップグレード時に設定が失われないように、.NETユーザー設定の場所を制御できますか？

user.configファイルの場所をカスタマイズしようとしています。現在、ハッシュとバージョン番号で保存されています

%AppData%\[CompanyName]\[ExeName]_Url_[some_hash]\[Version]\

アプリケーションのバージョンにとらわれないようにしたい

%AppData%\[CompanyName]\[ProductName]\

これはどのように行うことができますか？どのような影響がありますか？アップグレード後、ユーザーは以前のバージョンの設定を失いますか？

最初の質問に答えるには、技術的にはファイルを好きな場所に置くことができますが、ファイルの移動先のデフォルトの場所は2つの例の最初であるため、自分でコーディングする必要があります。（自分で行う方法へのリンク）

2番目の質問については、アプリケーションのデプロイ方法によって異なります。.msiを介して展開する場合、セットアッププロジェクト（msiのビルド元）のプロパティには、「アップグレードコード」と「製品コード」の2つのハッシュがあります。これらは、msiのインストール方法を決定し、それがアップグレード、上書き、または同じアプリケーションの他のバージョンの横にインストールされるかどうかを決定します。

たとえば、ソフトウェアに2つのバージョンがあり、それらに異なる「アップグレード」コードがある場合、ウィンドウに対しては、名前が何であるかに関係なく、ソフトウェアの完全に異なる部分です。ただし、「アップグレード」コードは同じであるが「製品」コードが異なる場合、2番目のmsiをインストールしようとすると、アップグレードするかどうかを尋ねられます。アップグレードするときに、古い構成から新しい構成へ。両方の値が同じで、バージョン番号が変更されていない場合、新しい構成は古い構成と同じ場所にあり、何もする必要はありません。 MSDNドキュメント

ClickOnceは少し異なります。これは、ClickOnceのバージョン番号とURLパスに基づいているためですが、同じ場所に「発行」し続ける限り、アプリケーションの新しいバージョンは引き続き使用します。既存の構成。（ClickOnceが更新を処理する方法へのリンク）

カスタムインストールスクリプトを使用してmsiのインストール中に手動で構成をマージする方法があることも知っていますが、その正確な手順を覚えていません...（Webでそれを行う方法については、このリンクを参照してください。構成）

私はこの引用されたテキストを、将来この問題が発生したときの参照として追加したかったのです。おそらく、ApplicationSettingsインフラストラクチャに、Upgradeを呼び出して、以前のバージョンから設定をコピーするように指示できます。

Properties.Settings.Value.Upgrade();

クライアント設定よくある質問：ブログ記事（アーカイブ）

Q：user.configパスにバージョン番号があるのはなぜですか？アプリケーションの新しいバージョンをデプロイした場合、ユーザーは以前のバージョンで保存されたすべての設定を失うのではないですか？

A：user.configパスがバージョン依存である理由はいくつかあります。

（1）アプリケーションの異なるバージョンのサイドバイサイドデプロイメントをサポートする（たとえば、これはClickonceで実行できます）。アプリケーションのバージョンが異なると、異なる設定が保存される可能性があります。

（2）アプリケーションをアップグレードすると、設定クラスが変更され、保存されたものと互換性がない可能性があり、問題が発生する可能性があります。

ただし、設定を以前のバージョンのアプリケーションから最新のバージョンに簡単にアップグレードできるようになりました。ApplicationSettingsBase.Upgrade（）を呼び出すだけ で、クラスの現在のバージョンと一致する以前のバージョンの設定が取得され、現在のバージョンのuser.configファイルに保存されます。また、設定クラスまたはプロバイダー実装のいずれかでこの動作をオーバーライドするオプションもあります。

Q：承知しましたが、アップグレードをいつ呼び出すかはどうすればわかりますか？

A：良い質問です。Clickonceでは、アプリケーションの新しいバージョンをインストールすると、ApplicationSettingsBaseがそれを検出し、設定が読み込まれた時点で設定を自動的にアップグレードします。Clickonce以外の場合、自動アップグレードはありません。自分でUpgradeを呼び出す必要があります。次に、アップグレードを呼び出すタイミングを決定するための1つのアイデアを示します。

CallUpgradeと呼ばれるブール設定があり、デフォルト値をtrueにします。アプリが起動したら、次のようなことができます。

if (Properties.Settings.Value.CallUpgrade)
{
   Properties.Settings.Value.Upgrade();
   Properties.Settings.Value.CallUpgrade = false;    
}

これにより、新しいバージョンがデプロイされた後、アプリケーションが初めて実行されるときにのみUpgrade（）が呼び出されます。

私はそれが実際に機能する可能性があることを一瞬信じません-Microsoftがこの機能を提供する方法はありませんが、方法はまったく同じです。

user.configファイルは、

c:\Documents and Settings>\<username>\[Local Settings\]Application Data\<companyname>\<appdomainname>_<eid>_<hash>\<verison>

<c:\Documents and Settings>非ローミング（上記のローカル設定）またはローミングのいずれかのユーザーデータディレクトリです。
<username>ユーザー名です。
<companyname>利用可能な場合、CompanyNameAttribute値です。それ以外の場合は、この要素を無視してください。
<appdomainname>AppDomain.CurrentDomain.FriendlyNameです。通常、これはデフォルトで.exe名になります。
<eid>ハッシュ可能な証拠に基づくURL、StrongName、またはPathです。
<hash>は、CurrentDomainから収集された証拠のSHA1ハッシュであり、優先順位は次のとおり
です。1. StrongName
2. URL：
どちらも使用できない場合は、.exeパスを使用します。
<version>AssemblyInfoのAssemblyVersionAttribute設定です。

詳細な説明はこちらhttp://msdn.microsoft.com/en-us/library/ms379611.aspx

（これを@Amrの回答へのコメントとして追加しますが、まだそれを行うのに十分な担当者がいません。）

MSDN記事の情報は非常に明確で、まだ適用されているようです。ただし、SHA1ハッシュは、より一般的な16進数ではなく、32進数でエンコードされて書き出されることは述べていません。

使用されているアルゴリズムはに実装されていると思いますToBase32StringSuitableForDirName。これは、Microsoft Reference Sourceにあります。