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


104

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?


Mentre la risposta di uzbones è informativa per quanto riguarda la posizione del file, credo che quella di Ian sia più corretta per quanto riguarda l'aggiornamento.
Anthony Mastrean

4
@AnthonyMastrean personalmente penso che qualsiasi impostazione importante non dovrebbe fare affidamento sull'infrastruttura ApplicationSettings fornita dal mio Microsoft. Muxa dovrebbe semplicemente memorizzare le impostazioni in %AppData%\[CompanyName]/[ProductName]cui possiamo fidarci che rimarranno.
Ian Boyd

2
Senza dubbio, la mia continua esperienza con l'applicazione integrata e le impostazioni utente è stata terribile. Raccomando i file json in appdata o programdata.
Anthony Mastrean

Puoi anche memorizzare le tue impostazioni in un registro. Vedi stackoverflow.com/a/12127888/1273550 per l'implementazione della classe di impostazioni alternative.
Ravi Patel

Risposte:


39

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)


Il codice di aggiornamento non è quello che dovrebbe rimanere costante e il codice del prodotto quello che dovrebbe cambiare tra le versioni? blogs.msdn.com/b/pusu/archive/2009/06/10/understanding-msi.aspx
estanford

Doh! hai ragione, non posso credere di averlo preso al contrario (e ci sono voluti 2 anni per prenderlo). È stato come firmare robo per un po 'di tempo nel mio passato :(
uzbones

Ciò significa che solo l'utente che esegue l'installazione ottiene l'aggiornamento delle sue impostazioni?
Micha Wiedenmann

79

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.


3
QUESTO FUNZIONA COMPLETAMENTE! Ho usato solo la semplice if(CallUpgrade) { Upgrade(); }dichiarazione.
Anthony Mastrean

@ Ian Boyd: Mi piace questa idea e sono totalmente entusiasta di avere una potenziale soluzione, tuttavia sono confuso su una cosa. Io non ho un Properties.Settings.Value ho la Properties.Settingsparte, ma mi sto perdendo qualcosa o è quella specifica per te?
Paladino Riformato

8
Funziona bene, ma ricordo ai lettori che il percorso della configurazione fino a ma escluso il numero di versione deve essere lo stesso. cioè vedi la risposta di @ Amr. ad esempio, se una nuova versione dell'app viene avviata da un percorso file diverso rispetto a una versione precedente, Upgradenon funziona.
Stephen Swensen

1
@RefractedPaladin èProperties.Settings.Default.Upgrade()
Stephen Swensen

5
Non dimenticare di aggiungere Properties.Settings.Default.Save();dopo averlo modificato in false :-)
Jeff

32

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


Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.