Posso controllare la posizione delle impostazioni utente .NET per evitare di perdere le impostazioni durante l'aggiornamento dell'applicazione?

Sto cercando di personalizzare la posizione del user.configfile. Attualmente è archiviato con un hash e un numero di versione

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

Voglio che sia agnostico rispetto alla versione dell'applicazione

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

Può essere fatto e come? Quali sono le implicazioni? L'utente perderà le impostazioni della versione precedente dopo l'aggiornamento?

Per rispondere alla prima domanda, tecnicamente puoi mettere il file dove vuoi, tuttavia dovrai codificarlo tu stesso, poiché il luogo predefinito in cui va il file è il primo dei tuoi due esempi. ( link a come farlo da solo )

Per quanto riguarda la seconda domanda, dipende da come distribuisci l'applicazione. Se si distribuisce tramite un .msi, ci sono due hash nelle proprietà del progetto di installazione (da cui è stato creato l'msi), il "codice di aggiornamento" e il "codice del prodotto". Questi determinano la modalità di installazione di msi e se aggiorna, sovrascrive o installa accanto a qualsiasi altra versione della stessa applicazione.

Ad esempio, se hai due versioni del tuo software e hanno codici di "aggiornamento" diversi, per Windows sono pezzi di software completamente diversi indipendentemente dal nome. Tuttavia, se il codice "aggiornamento" è lo stesso, ma il codice "prodotto" è diverso, quando proverai a installare il secondo msi ti verrà chiesto se desideri eseguire l'aggiornamento, momento in cui dovrebbe copiare i valori dal vecchia configurazione in una nuova configurazione. Se entrambi i valori sono uguali e il numero di versione non è cambiato, la nuova configurazione sarà nella stessa posizione della vecchia configurazione e non dovrà fare nulla. Documentazione MSDN

ClickOnce è leggermente diverso, perché si basa maggiormente sulla versione di ClickOnce # e sul percorso dell'URL, tuttavia ho scoperto che finché continui a "Pubblica" nella stessa posizione, la nuova versione dell'applicazione continuerà a utilizzare il configurazione esistente ( collegamento a come ClickOnce gestisce gli aggiornamenti )

So anche che esiste un modo per unire manualmente le configurazioni durante l'installazione di msi utilizzando script di installazione personalizzati, ma non ricordo i passaggi esatti per farlo ... (vedi questo link per come farlo con un file web. config)

Volevo aggiungere questo testo citato come riferimento per quando avrò questo problema in futuro. Presumibilmente puoi istruire l'infrastruttura ApplicationSettings per copiare le impostazioni da una versione precedente chiamando Upgrade :

Properties.Settings.Value.Upgrade();

Dal post del blog delle domande frequenti sulle impostazioni del client : ( archivio )

D: Perché c'è un numero di versione nel percorso user.config? Se distribuisco una nuova versione della mia applicazione, l'utente non perderà tutte le impostazioni salvate dalla versione precedente?

R: Ci sono un paio di ragioni per cui il percorso user.config è sensibile alla versione.

(1) Per supportare la distribuzione side-by-side di diverse versioni di un'applicazione (puoi farlo con Clickonce, ad esempio). È possibile che diverse versioni dell'applicazione abbiano diverse impostazioni salvate.

(2) Quando si aggiorna un'applicazione, la classe delle impostazioni potrebbe essere stata modificata e potrebbe non essere compatibile con ciò che è stato salvato, il che può causare problemi.

Tuttavia, abbiamo semplificato l'aggiornamento delle impostazioni da una versione precedente dell'applicazione all'ultima. Chiama semplicemente ApplicationSettingsBase.Upgrade () e recupererà le impostazioni dalla versione precedente che corrispondono alla versione corrente della classe e le memorizzerà nel file user.config della versione corrente. Hai anche la possibilità di sovrascrivere questo comportamento nella classe delle impostazioni o nell'implementazione del provider.

D: Va bene, ma come faccio a sapere quando chiamare Upgrade?

A: Bella domanda. In Clickonce, quando installi una nuova versione dell'applicazione, ApplicationSettingsBase la rileverà e aggiornerà automaticamente le impostazioni nel punto in cui vengono caricate le impostazioni. In casi diversi da Clickonce, non è previsto l'aggiornamento automatico: devi chiamare Upgrade tu stesso. Ecco un'idea per determinare quando chiamare Upgrade:

Avere un'impostazione booleana chiamata CallUpgrade e assegnargli un valore predefinito true. Quando la tua app si avvia, puoi fare qualcosa come:

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

Ciò garantirà che Upgrade () venga chiamato solo la prima volta che l'applicazione viene eseguita dopo la distribuzione di una nuova versione.

Non credo per un secondo che possa effettivamente funzionare - non c'è modo che Microsoft possa fornire questa capacità, ma il metodo è lo stesso.

Il file user.config è archiviato in

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

<c:\Documents and Settings>è la directory dei dati utente, non in roaming (Impostazioni locali sopra) o in roaming.
<username>è il nome utente.
<companyname>è il valore CompanyNameAttribute, se disponibile. Altrimenti, ignora questo elemento.
<appdomainname>è l'AppDomain.CurrentDomain.FriendlyName. Di solito il valore predefinito è il nome .exe.
<eid>è l'URL, StrongName o Path, in base all'evidenza disponibile per l'hash.
<hash>è un hash SHA1 di prove raccolte da CurrentDomain, nel seguente ordine di preferenza:
1. StrongName
2. URL:
se nessuno di questi è disponibile, utilizzare il percorso .exe.
<version>è l'impostazione AssemblyVersionAttribute di AssemblyInfo.

La descrizione completa è qui http://msdn.microsoft.com/en-us/library/ms379611.aspx

(Lo aggiungerei come commento alla risposta di @ Amr, ma non ho ancora abbastanza rappresentante per farlo.)

Le informazioni nell'articolo MSDN sono molto chiare e sembrano essere ancora valide. Tuttavia non si menziona che l'hash SHA1 è scritto con codifica base 32, piuttosto che la più tipica base 16.

Credo che l'algoritmo utilizzato sia implementato in ToBase32StringSuitableForDirName, che può essere trovato qui in Microsoft Reference Source .