Kiedy - i dlaczego - należy przechowywać dane w rejestrze systemu Windows?

Jako programista narzędzia przechowujące konfigurację / opcje w rejestrze są zmorą mojego życia. Nie mogę łatwo śledzić zmian w tych opcjach, nie mogę łatwo przenosić ich z komputera na komputer, a to wszystko sprawia, że ​​naprawdę tęsknię za starymi, dobrymi czasami plików .INI ...

Pisząc własne aplikacje, co - jeśli w ogóle - powinienem umieścić w rejestrze zamiast w staromodnych plikach konfiguracyjnych i dlaczego?

• Pierwotnie konfiguracja (WIN3) była przechowywana w pliku WIN.INI w katalogu systemu Windows.
• Problem: WIN.INI urósł za duży.
• Rozwiązanie (Win31): pojedyncze pliki INI w tym samym katalogu co program.
• Problem: Ten program może być zainstalowany w sieci i współdzielony przez wiele osób.
• Rozwiązanie (Win311): pojedyncze pliki INI w katalogu Windows użytkownika.
• Problem: Wiele osób może współdzielić folder Windows, a mimo to powinien on być tylko do odczytu.
• Rozwiązanie (Win95): Rejestr z oddzielnymi sekcjami dla każdego użytkownika.
• Problem: Rejestr urósł za duży.
• Rozwiązanie (WinXP): duże bloki pojedynczych danych przeniesione do folderu danych aplikacji użytkownika.
• Problem: Dobre w przypadku dużych ilości danych, ale raczej złożone w przypadku małych ilości.
• Rozwiązanie (.NET): niewielkie ilości stałych, tylko do odczytu danych przechowywanych w plikach .config (Xml) w tym samym folderze co aplikacja, z interfejsem API do ich odczytu. (Dane do odczytu / zapisu lub dane użytkownika pozostają w rejestrze)

Patrząc na to zarówno z perspektywy użytkownika, jak i programisty, muszę powiedzieć, że naprawdę nie ma dobrego powodu, aby umieścić coś w rejestrze, chyba że jest to coś w rodzaju skojarzeń plików lub ustawień specyficznych dla komputera.

Wywodzę się ze szkoły myślenia, która mówi, że program powinien być uruchamiany z dowolnego miejsca, w którym jest zainstalowany, że instalacja powinna być całkowicie przenośna w obrębie maszyny lub nawet na inną maszynę i nie wpływać na jej działanie.

Wszelkie konfigurowalne opcje, wymagane biblioteki DLL itp., Jeśli nie są udostępniane, powinny znajdować się w podkatalogu katalogu instalacyjnego, aby można było łatwo przenieść całą instalację.

Używam wielu mniejszych narzędzi, takich jak programy, więc jeśli nie można go zainstalować na pendrive'ie i podłączyć do innego komputera i po prostu uruchomić, to nie jest dla mnie.

Polityka firmy Microsoft:

• Przed Windows 95 używaliśmy plików ini do danych aplikacji.
• W erze Windows 95 - XP korzystaliśmy z rejestru.
• W systemie Windows Vista używamy plików ini, chociaż są one teraz oparte na formacie XML.

Rejestr jest zależny od komputera. Nigdy mi się to nie podobało, ponieważ robi się powoli i prawie niemożliwe jest znalezienie tego, czego potrzebujesz. Dlatego lubię proste pliki ini lub inne pliki ustawień. Wiesz, gdzie się znajdują (folder aplikacji lub folder użytkownika), więc są łatwe w przenoszeniu i czytelne dla człowieka.

Kiedy - jesteś zmuszony ze względu na starszą integrację lub dlatego, że administrator systemu Twojego klienta mówi „tak powinno być” lub ponieważ tworzysz program w starszym języku, który utrudnia korzystanie z XML.

Czemu Przede wszystkim dlatego, że rejestr nie jest tak przenośny, jak kopiowanie pliku konfiguracyjnego, który znajduje się obok aplikacji (i nazywa się prawie tak samo).

Jeśli używasz .Net2 +, masz pliki App.Config i User.Config i nie musisz rejestrować bibliotek DLL w rejestrze, więc trzymaj się od nich z daleka.

Pliki konfiguracyjne mają swoje własne problemy (patrz poniżej), ale można je zakodować i zmienić architekturę.

• Problem: aplikacje wymagały ustawień konfigurowalnych.
• Rozwiązanie: Zapisz ustawienia w pliku (WIN.INI) w folderze Windows - użyj nagłówków sekcji, aby pogrupować dane (Win3.0).
• Problem: plik WIN.INI urósł za duży (i zaczął się brudzić).
• Rozwiązanie: Zapisz ustawienia w plikach INI w tym samym folderze co aplikacja (Win3.1).
• Problem: potrzebne są ustawienia specyficzne dla użytkownika.
• Rozwiązanie: Zapisz ustawienia użytkownika w plikach INI specyficznych dla użytkownika w katalogu Windows użytkownika (Win3.11) lub sekcjach specyficznych dla użytkownika w pliku INI aplikacji.
• Problem: Bezpieczeństwo - niektóre ustawienia aplikacji muszą być tylko do odczytu.
• Rozwiązanie: Rejestr z zabezpieczeniami oraz sekcjami dotyczącymi użytkownika i całego komputera (Win95).
• Problem: Rejestr urósł za duży.
• Rozwiązanie: Rejestr specyficzny dla użytkownika został przeniesiony do user.dat we własnym folderze „Dane aplikacji” użytkownika i załadowany tylko przy logowaniu (WinNT).
• Problem: W dużych środowiskach korporacyjnych logujesz się na wielu komputerach i musisz skonfigurować KAŻDY.
• Rozwiązanie: Rozróżnij profile lokalne (ustawienia lokalne) i profile mobilne (dane aplikacji) (WinXP).
• Problem: nie można xcopy wdrożyć lub przenieść aplikacji, tak jak reszta .Net.
• Rozwiązanie: Plik APP.CONFIG XML w tym samym folderze co aplikacja - łatwy do odczytania, łatwy w manipluacji, łatwy do przenoszenia, możliwość śledzenia zmian (.Net1).
• Problem: Nadal trzeba przechowywać dane specyficzne dla użytkownika w podobny sposób (tj. Wdrażanie xcopy).
• Rozwiązanie: plik XML USER.CONFIG w folderze lokalnym lub mobilnym użytkownika i wpisany jednoznacznie (.Net2).
• Problem: w plikach CONFIG rozróżniana jest wielkość liter (nie jest to intuicyjne dla ludzi), wymagają bardzo konkretnych „tagów” ​​otwierania / zamykania, parametrów połączenia nie można ustawić w czasie wykonywania, projekty konfiguracyjne nie mogą zapisywać ustawień (tak łatwo jak w rejestrze), nie można ich łatwo określić Plik user.config i ustawienia użytkownika są wydmuchiwane przy każdej zainstalowanej nowej wersji.
• Rozwiązanie: Użyj elementu członkowskiego ITEM, aby ustawić parametry połączenia w czasie wykonywania, napisz kod w klasie Instalator, aby zmienić App.Config podczas instalacji i użyj ustawień aplikacji jako domyślnych, jeśli nie zostanie znalezione ustawienie użytkownika.

Czy świat się skończy, jeśli zapiszesz kilka pozycji okien i listę ostatnio używanych elementów w rejestrze systemu Windows? Jak na razie działa dobrze.

HKEY-CURRENT-USER to świetne miejsce do przechowywania banalnych danych użytkownika w niewielkich ilościach. Po to jest. Wydaje się głupie, aby nie używać go zgodnie z jego przeznaczeniem tylko dlatego, że inni go nadużyli.

Ustawienia, które chcesz mieć dostępne w profilu mobilnym użytkownika, powinny prawdopodobnie trafić do rejestru, chyba że faktycznie chcesz spróbować ręcznie wyszukać folder danych aplikacji użytkownika. :-)

Odczyty i zapisy rejestru są bezpieczne wątkowo, ale pliki nie. Zależy to więc od tego, czy Twój program jest jednowątkowy, czy nie.

Jeśli tworzysz nową aplikację i zależy Ci na przenośności, NIGDY nie powinieneś przechowywać danych w rejestrze systemu Windows, ponieważ inny system operacyjny nie ma rejestru (Windows) (uwaga - może to być oczywiste, ale często jest pomijane).

Jeśli tworzysz tylko dla platform Win ... staraj się tego unikać tak bardzo, jak to możliwe. Pliki konfiguracyjne (prawdopodobnie zaszyfrowane) są o wiele lepszym rozwiązaniem. Nie ma korzyści z przechowywania danych w rejestrze - (izolowana pamięć jest znacznie lepszym rozwiązaniem, na przykład, jeśli używasz .NET).

Trochę nie na temat, ale ponieważ widzę ludzi zaniepokojonych przenośnością, najlepszym podejściem, jakiego kiedykolwiek używałem, jest klasa QSettings w Qt. Ogranicza przechowywanie ustawień (rejestr w systemie Windows, plik preferencji XML w systemie Mac OS i pliki Ini w systemie Unix). Jako klient zajęć nie muszę tracić czasu na zastanawianie się nad rejestrem czy czymkolwiek innym, to Just Works (tm).

http://doc.trolltech.com/4.4/qsettings.html#details

Zwykle, jeśli nie umieszczasz ustawień w rejestrze, używasz go głównie do pobierania aktualnych ustawień systemu Windows, zmiany skojarzeń plików itp.
Teraz, jeśli chcesz wykryć, czy oprogramowanie jest już zainstalowane, możesz zrobić minimalny wpis w rejestrze , to lokalizacja, którą możesz znaleźć w dowolnej konfiguracji. Lub wyszukaj folder o podanej nazwie w danych aplikacji.

Jeśli spojrzę na mój folder Document and Settings, widzę wiele programów używających uniksowej notacji kropkowej do ustawiania folderów: .p4qt .sqlworkbench .squirrel-sql .SunDownloadManager .xngr .antexplorer .assistant .CodeBlocks .dbvis .gimp-2.4 .jdictionary. .jindent .jogl_ext (itp.)

oraz w danych aplikacji, różne foldery z nazwami redaktorów lub nazwami oprogramowania. Wygląda na to, że jest to aktualny trend, przynajmniej wśród aplikacji przenośnych ...
WinMerge używa nieco innego podejścia, przechowując dane w rejestrze, ale oferując opcje importu i eksportu w oknie konfiguracji.

Osobiście korzystałem z rejestru do przechowywania ścieżek instalacji do użycia przez skrypty (nie) instalacyjne. Nie jestem pewien, czy jest to jedyna możliwa opcja, ale wydawało się to rozsądnym rozwiązaniem. Dotyczyło to oczywiście aplikacji, która była używana wyłącznie w systemie Windows.

W .NET naprawdę nie ma takiej potrzeby.

Oto 2 przykłady, które pokazują, jak użyć właściwości projektu, aby to zrobić.

Te przykłady robią to za pomocą właściwości projektu użytkownika systemu Windows, ale to samo może / może być również zrobione przez aplikację.

Więcej tutaj:

http://code.msdn.microsoft.com/TheNotifyIconExample

http://code.msdn.microsoft.com/SEHE

(późno do dyskusji, ale) Krótka odpowiedź: Zasady grupy.

Jeśli dział IT klienta chce wymusić ustawienia związane z systemem Windows lub komponentami, które piszesz lub w których piszesz, takie jak szybkość łącza, niestandardowy komunikat o błędzie lub serwer bazy danych, z którym chcesz się połączyć, nadal jest to zazwyczaj odbywa się za pośrednictwem zasad grupy, co ostatecznie objawia się jako ustawienia przechowywane w rejestrze. Takie zasady są wymuszane od momentu uruchomienia systemu Windows lub zalogowania się użytkownika.

Istnieją narzędzia do tworzenia niestandardowych szablonów ADMX, które mogą mapować ustawienia komponentów do lokalizacji w rejestrze i zapewniają administratorowi wspólny interfejs do egzekwowania zasad, które musi egzekwować, pokazując im tylko te ustawienia, które są istotne do wymuszenia w ten sposób.

Uważam, że Rejestr systemu Windows był dobrym pomysłem, ale z powodu wielkich nadużyć ze strony twórców aplikacji i standardowych zasad, których Microsoft nie zachęcał / nie nakazał, stał się bestią, której nie da się opanować. Nienawidzę go używać z powodów, o których wspomniałeś, są jednak sytuacje, w których ma sens:

• Pozostawienie śladu aplikacji po odinstalowaniu aplikacji (np. Zapamiętanie preferencji użytkownika w przypadku ponownej instalacji aplikacji)
• Współdziel ustawienia konfiguracji między różnymi aplikacjami - komponentami