2010-03-19 11 views
28

Utworzyłem aplikację, która używa ustawień settings.settings do przechowywania określonych ustawień użytkownika (scope = User). Ustawienia są poprawnie ładowane przy starcie, zmienione podczas używania i poprawnie zapisane do następnego uruchomienia. Ten cykl wydaje się nie mieć żadnych problemów.Jak utrzymać zmiany w pliku .settings/.config przez zmianę wersji pliku?

Problem pojawia się, gdy aktualizuję wersje zespołów i plików dla nowej kompilacji. Ustawienia nie są już ładowane podczas uruchamiania (zamiast tego używane są wartości domyślne). Okazuje się także, że plik konfiguracyjny zapisany z wersji 1.1 będzie się utrzymywał nawet po uruchomieniu wersji 1.2 i wygenerowaniu NOWYM pliku konfiguracyjnym oraz zapisaniu (tzn. Można ponownie uruchomić wersję 1.1, a plik konfiguracyjny będzie plikiem konfiguracyjnym, który został zapisany z tego pliku wersja).

Wygląda więc na to, że ustawienia są specyficzne dla wersji zespołu i/lub pliku. Warto również zauważyć, że między wersją 1.1 a wersją 1.2 nie było żadnych zmian w pliku settings.settings ani w żadnej innej sprawie (tj. Jedyną zmianą, którą wprowadziłem między tymi różnymi kompilacjami było zmodyfikowanie numerów wersji).

Czy istnieje sposób na utrzymanie tych ustawień dla zmian wersji?

+0

[Zachowanie ustawień między aktualizacjami] (https://stackoverflow.com/questions/534261/how-do-you-keep-user-config-settings-across-different-assembly-instrument-in-net/534335# 534335) może być kolejnym wyzwaniem podczas używania klasy Ustawienia .Net. Link na początku tego postu zawiera odpowiedź. –

+0

Umieściłem możliwe rozwiązanie w [tym wątku] (https://stackoverflow.com/a/47921377/3223783). Mam nadzieję, że pomaga! – dontbyteme

+0

Opublikowałem możliwe rozwiązanie w następującym wątku: https://stackoverflow.com/a/47921377/3223783 Mam nadzieję, że to pomaga! – dontbyteme

Odpowiedz

18

Markus Olsson dał już całkiem niezłą odpowiedź: here.

Zasadniczo konieczne będzie użycie metody ApplicationSettingsBase.Upgrade().

+0

Dziękuję za informację! Jest teraz skompilowany, przetestowany, działa zgodnie z oczekiwaniami i jest teraz w pełni zintegrowany z projektem !! Przyznam ci nagrodę, kiedy będę mógł (najwyraźniej muszę poczekać, aby przyjąć tę odpowiedź - powinna być później dzisiaj lub jutro). : D – InvertedAcceleration

1

Mam nadzieję, że ktoś inny ma lepszą odpowiedź. Miałem to pytanie kilka lat temu, a jedynym rozwiązaniem, jakie mogłem znaleźć (które działało) było użycie mojego własnego mechanizmu do przechowywania ustawień, a nie domyślnego wbudowanego sposobu .NET.

+0

Dzięki za chipping w swoim doświadczeniu ... Jestem zdumiony Nie mam odpowiedzi w tej chwili, która jest prosta i prosta (zarówno przez SO i ja próbując odpowiedzieć na to sam w dokumentach). Prowadzi mnie to do przekonania, że ​​nie jest możliwe ...co jest szalone, ponieważ to, co wydaje się świetną funkcją oszczędzania czasu, jest niemal całkowicie bezużyteczne w przypadku większości projektów. – InvertedAcceleration

41

Kilka wyjaśnień:

Trzeba wywołać metodę Upgrade z ApplicationSettingsBase klasie pochodnej (który jest zwykle o nazwie Settings i jest stworzony dla Ciebie przez Visual Studio):

Properties.Settings.Default.Upgrade(); 

Kiedy/gdzie zadzwonić na metodę Upgrade? Istnieje prosta sztuczka, którą możesz zastosować: zdefiniuj ustawienie użytkownika o nazwie UpgradeRequired (przykład) jako bool (najprostszy sposób to IDE). Upewnij się, że jego domyślna wartość to true.

Wstaw ten kod snipped na początku stosowania:

if (Properties.Settings.Default.UpgradeRequired) 
    { 
     Properties.Settings.Default.Upgrade(); 
     Properties.Settings.Default.UpgradeRequired = false; 
     Properties.Settings.Default.Save(); 
    } 

Więc metoda Uaktualnienie zostanie wywołana tylko po zmianach wersji i tylko jeden raz (od wyłączenia dalszych uaktualnień poprzez ustawienie UpgradeRequired = false aż wersji change - gdy właściwość odzyska domyślną wartość true).

+2

Zamiast/w uzupełnieniu do 'UpgradeRequired', chciałbym przechowywać wersję aplikacji jako ustawienie. Pozwala to na przeprowadzenie niestandardowych konwersji uaktualnień (tj. Nieprawidłowej wartości/poprawnej wartości na inną niż domyślna wartość/-same najnowszej wersji). Możesz mieć kod, który konwertuje każdą odpowiednią wersję wymagającą konwersji do następnej, wymagającej wersji i łączy w łańcuchy kodu, a przez to: a) zmniejsza złożoność kodu konwersji najnowszej wersji i b) umożliwia potencjalne wycofanie starego kodu konwersji. – Tom

Powiązane problemy