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

StackOverflow https://stackoverflow.com/questions/621265

  •  05-07-2019
  •  | 
  •  

質問

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

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

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

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

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

役に立ちましたか？

解決

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

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

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

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

カスタムインストールスクリプトを使用してmsiのインストール中に構成を手動でマージする方法もありますが、それを行うための正確な手順は覚えていません...（この web.configで行う方法のリンク）

他のヒント

今後この問題が発生した場合の参考として、この引用テキストを追加したかった。おそらく、アップグレード：

Properties.Settings.Value.Upgrade();

クライアント設定に関するよくある質問のブログ投稿：（アーカイブ）

  

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

     

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

     

（1）並列展開をサポートするには   の異なるバージョンの   アプリケーション（これを行うことができます   たとえば、Clickonce）。それは   の異なるバージョンで可能   異なる設定を持つアプリケーション   保存しました。

     

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

     

ただし、簡単に   以前の設定をアップグレードする   アプリケーションのバージョン   最新。単に電話する    ApplicationSettingsBase.Upgrade（）および   から設定を取得します   に一致する以前のバージョン   クラスとストアの現在のバージョン   それらを現在のバージョンの   user.configファイル。あなたも持っています   この動作をオーバーライドするオプション   設定クラスまたは   プロバイダーの実装。

     

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

     

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

     

ブール設定を呼び出します   CallUpgradeにデフォルトを設定します   真の値。アプリが起動するとき   次のようなことができます：

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にあります。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top