Коли і чому потрібно зберігати дані в реєстрі Windows?

Як розробник, інструменти, які зберігають конфігурацію / параметри в реєстрі, є основою мого життя. Я не можу легко відстежувати зміни в цих параметрах, не можу легко перенести їх з машини на машину, і все це змушує мене дуже прагнути старих старих файлів .INI.

Коли я пишу власні додатки, що - якщо що - я повинен вибрати в реєстр, а не в старомодні конфігураційні файли, і чому?

• Спочатку конфігурація (WIN3) зберігалася у файлі WIN.INI у каталозі Windows.
• Проблема: WIN.INI виріс дуже великий.
• Рішення (Win31): окремі файли INI в тій же директорії, що і програма.
• Проблема. Ця програма може бути встановлена ​​в мережі та поділитися багатьма людьми.
• Рішення (Win311): окремі файли INI у каталозі вікна користувача.
• Проблема: Багато людей можуть мати спільну папку Windows, і вона має бути доступною лише для читання.
• Рішення (Win95): реєстр з окремими розділами для кожного користувача.
• Проблема: реєстр став занадто великим.
• Рішення (WinXP): великі блоки окремих даних переміщені у власну папку Дані програми.
• Проблема: добре для великих обсягів даних, але досить складний для невеликих обсягів.
• Рішення (.NET): невелика кількість фіксованих даних, доступних лише для читання, що зберігаються у файлах .config (Xml) у тій же папці, що і додаток, з API для її читання. (Читання / запис або певні користувацькі дані залишаються в реєстрі)

Якщо говорити про це як з точки зору користувача, так і з точки зору програмістів, я б сказав, що насправді не надто корисне, щоб щось помістити в реєстр, якщо це не щось на зразок асоціацій файлів чи певних налаштувань машини.

Я походить із школи думок, яка говорить про те, що програма повинна бути запущена з того місця, де вона встановлена, що інсталяція повинна бути повністю рухомою в межах машини або навіть на іншій машині і не впливати на її роботу.

Будь-які налаштовані параметри, або потрібні dll тощо, якщо вони не поділяються, повинні міститись у підкаталозі каталогу інсталяції, щоб вся установка легко переміщувалася.

Я використовую багато менших утиліт, таких як програми, тому якщо його не можна встановити на USB-накопичувач і підключити до іншої машини та просто запустити, то це не для мене.

Політика Microsoft:

• Перед Windows 95 ми використовували файли ini для даних програми.
• У епоху Windows 95 - XP ми використовували реєстр.
• У Windows Vista ми використовуємо файли ini, хоча зараз вони засновані на XML.

Реєстр залежить від машини. Мені це ніколи не подобалося, тому що його стає повільним і майже неможливо знайти потрібну річ. Ось чому мені подобаються прості ini чи інші налаштування файлів. Ви знаєте, де вони знаходяться (папка додатків чи папка користувача), тому вони легко переносяться та читаються людиною.

Коли - ви змушені через застарілу інтеграцію або через те, що системний адміністратор вашого клієнта каже, що "так буде", або тому, що ви розробляєте стару мову, що ускладнює використання XML.

Чому - Перш за все тому, що реєстр не такий портативний, як копіювання файлу конфігурації, який сидить поруч із додатком (і називається майже таким же).

Якщо ви використовуєте .Net2 +, у вас є файли App.Config та User.Config, і вам не потрібно реєструвати DLL-файли в реєстрі, тому тримайтеся подалі від нього.

У файлах Config є свої проблеми (див. Нижче), але їх можна закодувати навколо, і ви можете змінити свою архітектуру.

• Проблема: Програми потребували налаштованих налаштувань.
• Рішення: Зберігайте налаштування у файлі (WIN.INI) у папці Windows - використовуйте заголовки розділів для групування даних (Win3.0).
• Проблема: файл WIN.INI виріс (і заплутався).
• Рішення: Зберігайте налаштування у файлах INI у тій самій папці, що і додаток (Win3.1).
• Проблема: потрібні налаштування для користувача.
• Рішення: Збережіть налаштування користувача у специфічних для користувача файлах INI у вікні каталогу користувача (Win3.11) або у розділах, визначених для користувача, у файлі INI програми.
• Проблема: Безпека - деякі параметри програми потрібно мати лише для читання.
• Рішення: Реєстр із захистом, а також специфічні для користувача та розділи на комп'ютері (Win95).
• Проблема: реєстр став занадто великим.
• Рішення: Реєстр, призначений для користувача, переміщено до user.dat у власній папці "Дані програми" та завантажується лише під час входу (WinNT).
• Проблема: У великих корпоративних середовищах ви входите на декілька машин і повинні налаштувати кожного.
• Рішення: розрізняйте локальні (локальні налаштування) та роумінгові (дані програми) (WinXP).
• Проблема. Неможливо xcopy розгортати або переміщувати додатки, як і решта .Net.
• Рішення: XP-файл APP.CONFIG у тій самій папці, що і додаток, - простий для читання, простий в маніпуляції, простий в переміщенні, може відслідковуватися при зміні (.Net1).
• Проблема: все-таки потрібно зберігати дані, характерні для користувача, аналогічним чином (тобто розгортання xcopy).
• Рішення: XER-файл USER.CONFIG у локальній або роумінговій папці користувача та сильно набраний (.Net2).
• Проблема: файли CONFIG чутливі до регістру (не інтуїтивно зрозумілі для людини), вимагають дуже специфічних відкритих / закритих "тегів", рядки підключення не можна встановлювати під час виконання, проекти налаштування не можуть записувати налаштування (так просто, як реєстр), не можуть легко визначити Файл user.config та налаштування користувача обдуваються при кожній встановленій новій версії.
• Рішення: Використовуйте член ITEM для встановлення рядків з'єднань під час виконання, введіть код у класі інсталятора, щоб змінити App.Config під час встановлення та використовувати параметри програми за замовчуванням, якщо налаштування користувача не знайдено.

Чи закінчиться світ, якщо ви збережете в реєстрі Windows кілька позицій вікна та список останніх використаних елементів? Для мене це все добре працює.

HKEY-CURRENT-USER - прекрасне місце для зберігання тривіальних даних користувачів у невеликих кількостях. Ось для чого це. Здається, нерозумно не використовувати за призначенням лише тому, що інші зловживали цим.

Налаштування, які ви хочете мати в роумінговому профілі користувача, ймовірно, повинні бути внесені до реєстру, якщо ви дійсно не хочете намагатися вручну шукати папку даних програми користувача вручну. :-)

Реєстр читає і записує безпечні нитки, але файли - ні. Отже, це залежить від того, чи є ваша програма однопоточною.

Якщо ви розробляєте новий додаток, і ви турбуєтесь про переносимість, НІКОЛИ не зберігайте дані в реєстрі Windows, оскільки інші ОС не мають реєстру (windows) (це зауважте - це може бути очевидним, але його часто не помічають).

Якщо ви розробляєте лише для платформ Win ... намагайтеся уникати цього, наскільки це можливо. Налаштування файлів (можливо, зашифрованих) є набагато кращим рішенням. Немає вигоди від зберігання даних у реєстрі - (ізольоване сховище є набагато кращим рішенням, наприклад, якщо ви використовуєте .NET).

Трохи поза темою, але, оскільки я бачу людей, занепокоєних портативністю, найкращим підходом, який я коли-небудь застосовував, є клас QSettings Qt. Він резюмує зберігання налаштувань (реєстр в Windows, файл переваг XML на Mac OS та файли Ini в Unix). Як клієнт класу, мені не доводиться проводити мозковий цикл, цікавлячись реєстру чи іншого, це просто працює (тм).

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

Зазвичай, якщо ви не вводите налаштування в реєстр, ви використовуєте їх в основному для отримання поточних налаштувань Windows, зміни асоціацій файлів тощо.
Тепер, якщо вам потрібно виявити, чи програмне забезпечення вже встановлено, ви можете зробити мінімальний запис у реєстрі , це місце, яке ви можете знайти в будь-якому конфігурації. Або шукайте папку з вказаним іменем у Дані програми.

Якщо я дивлюся на папку «Документи та налаштування», я бачу багато програмного забезпечення, яке використовує позначення крапок Unix для встановлення папок: .p4qt .sqlworkbench .squirrel-sql .SunDownloadManager .xngr .antexplorer .assistant .CodeBlocks .dbvis .gimp-2.4 .jdictionary .jindent .jogl_ext (тощо)

і в Дані програми, різні папки з іменами редактора або іменами програмного забезпечення. Схоже, це тенденція, щонайменше, серед портативних програм ...
WinMerge використовує дещо інший підхід, зберігаючи дані в реєстрі, але пропонуючи імпорт та експорт параметрів у діалоговому вікні конфігурації.

Особисто я використовував реєстр, щоб зберігати шляхи установки для використання сценаріями (не) встановлення. Я не впевнений, чи це єдино можливий варіант, але здавався розумним рішенням. Це було для програми, яка використовувалася виключно в Windows.

У .NET насправді НЕ ВІДПОВІСТЬ.

Ось два приклади, які показують, як використовувати proerties Project для цього.

Ці приклади роблять це за допомогою властивостей проекту користувача користувача Windows, але те саме можна зробити / застосувати і в програмі.

Більше тут:

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

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

(пізно до обговорення, але) Короткий відповідь: Групова політика.

Якщо відділ інформаційних технологій вашого клієнта хоче застосувати налаштування, пов’язані з Windows або компонентом, яким ви пишете чи вбудовуєте, наприклад швидкість посилання, або власне повідомлення про помилку або сервер бази даних, до якого потрібно підключитися, це як правило проводиться за допомогою групової політики, яка дає остаточний прояв як налаштування, що зберігаються в реєстрі. Такі правила застосовуються з часу запуску Windows або входу користувача.

Існують інструменти для створення користувальницьких шаблонів ADMX, які можуть зіставляти налаштування компонентів у місцях реєстрації та надавати адміністратору загальний інтерфейс для виконання політик, які він повинен застосовувати, показуючи їм лише ті параметри, які мають сенс для виконання цього способу.

Я вважаю, що Реєстр Windows був гарною ідеєю, але через великі зловживання розробниками програм та стандартними політиками, не заохоченими / розпорядженими Microsoft, перетворився на некерованого звіра. Я ненавиджу його використовувати з причин, про які ви згадали, проте є деякі випадки, коли є сенс використовувати його:

• Залишаючи слід від вашої програми після видалення вашої програми (наприклад, пам’ятайте про налаштування користувача у випадку, якщо програма буде встановлена ​​знову)
• Налаштування параметрів конфігурації між різними програмами - компонентами