什麼時候 - 爲什麼 - 應該將數據存儲在Windows註冊表中？

Question

作爲開發者，在註冊表中存儲配置/選項的工具是我生活中的禍根。我不能輕易跟蹤這些選項的變化，無法輕鬆地將它們逐一移植到機器，這一切都讓我真的渴望.INI文件的美好時光......

當編寫我自己的應用程序，我應該選擇放入註冊表而不是舊式配置文件，爲什麼？

Answer 1

• 最初（WIN3）配置存儲在Windows目錄中的WIN.INI文件中。
• 問題：WIN.INI變得太大了。
• 解決方案（Win31）：與程序位於同一目錄中的單個INI文件。
• 問題：該程序可能安裝在網絡上並被許多人共享。
• 解決方案（Win311）：用戶的Window目錄中的單個INI文件。
• 問題：很多人可能共享一個Windows文件夾，並且它應該是隻讀的。
• 解決方案（Win95）：註冊表，每個用戶都有獨立的部分。
• 問題：註冊表變得太大了。
• 解決方案（WinXP）：將大塊單個數據移至用戶自己的Application Data文件夾。
• 問題：適用於大量數據，但對於少量數據則相當複雜。
• 解決方案（.NET）：將少量固定的只讀數據存儲在與應用程序相同的文件夾中的.config（Xml）文件中，並使用API​​讀取它。 （讀/寫或用戶特定數據保留在註冊表中）

Answer 2

您希望在用戶的漫遊配置文件中可用的設置可能應該放在註冊表中，除非您真的想要手動查找用戶的Application Data文件夾。 :-)

Answer 3

Microsoft策略：

• 窗口95之前，我們使用INI文件的應用程序數據。
• 在windows 95-XP時代，我們使用了註冊表。
• 從Windows Vista開始，我們使用ini文件，儘管它們現在基於xml。

註冊表是機器相關的。我從來不喜歡它，因爲它變得緩慢，幾乎找不到你需要的東西。這就是爲什麼我喜歡簡單的ini或其他設置文件。您知道它們在哪裏（應用程序文件夾或用戶文件夾），因此它們易於攜帶，而且易於閱讀。

Answer 4

通常，如果您不將設置放入註冊表中，則主要用於獲取當前Windows設置，更改文件關聯等。
現在，如果您需要檢測您的軟件是否已安裝，您可以在註冊表中創建一個最小條目，這是您可以在任何配置中找到的位置。或者在應用程序數據中搜索給定名稱的文件夾。

如果我把我的文檔和設置文件夾，我看到很多使用Unix點符號設置文件夾軟件的： .p4qt .sqlworkbench .squirrel-SQL .SunDownloadManager .xngr .antexplorer 。助理 .CodeBlocks .dbvis .gimp-2.4 .jdictionary .jindent .jogl_ext（等）

和應用程序數據，與編輯的姓名或軟件不同的文件夾名。看起來像當前的趨勢，至少在便攜式應用程序...
WinMerge使用一種稍微不同的方法，將數據存儲在註冊表中，但在配置對話框中提供導入和導出選項。

Answer 5

如果你正在開發一個新的應用程序，你關心的可移植性，你應該，因爲其他的操作系統沒有（窗口）在Windows註冊表註冊表NEVER存儲數據（杜注 - 這可能是明顯的，但被常常被忽視）。

如果您只是爲Win平臺開發...儘量避免它。配置文件（可能是加密的）是更好的解決方案。將數據存儲到註冊表中沒有任何好處 - （例如，如果您使用.NET，隔離存儲是一個更好的解決方案）。

Answer 6

從用戶角度和程序員的角度來看，我不得不說，除非它是像文件關聯或機器特定設置之類的東西，否則確實不是一個很好的優先事項。

我來自思想流派，認爲程序應該可以從任何地方安裝，可以在機器內完全移動，甚至可以在另一臺機器上移動，不會影響程序的運行。

任何可配置的選項或所需的dll等（如果它們未被共享）應駐留在安裝目錄的子目錄中，以便整個安裝很容易移動。

我使用了很多像程序這樣的小工具，所以如果它不能被安裝在USB棒上並插入另一臺機器並運行，那麼它不適合我。

Answer 7

註冊表讀寫是線程安全的，但文件不是。所以這取決於你的程序是否是單線程的。

Answer 8

稍有偏離主題，但由於我看到關注可移植性的人，我曾經使用過的最好的方法是Qt的QSettings類。它抽象設置的存儲（Windows上的註冊表，Mac OS上的XML首選項文件和Unix上的Ini文件）。作爲班上的一名客戶，我不必花費大腦思考關於註冊表或其他任何事情的大腦循環，它只是工作（tm）。

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

Answer 9

我相信，Windows註冊表是一個好主意，但由於從應用開發商和微軟並不鼓勵/強制標準政策極大虐待增長陷入不可收拾的野獸。由於你提到的原因，我討厭使用它，但有些場合使用它是有意義的：

• 在應用程序卸載後留下你的應用程序的跟蹤（例如，記得在情況下，應用程序再次安裝用戶的偏好）不同的應用程序之間
• 共享配置設置 - 組件

Answer 10

難道世界將要結束，如果你保存了幾個窗口位置和最近使用的項目列表中Windows註冊表？到目前爲止，它對我來說還好。

HKEY-CURRENT-USER是一個很好的存儲小量用戶數據的好地方。這就是它的目的。僅僅因爲其他人濫用了它，它似乎很愚蠢。

Answer 11

就我個人而言，我已經使用註冊表來存儲（un）安裝腳本所使用的安裝路徑。我不確定這是否是唯一可行的選擇，但似乎是一個明智的解決方案。這是一個當然只在Windows上使用的應用程序。

Answer 12

當 - 您不得不因遺留系統集成或客戶的系統管理員說「應該是這樣」或者因爲您正在使用較舊的語言進行開發，這使得使用XML更加困難。

爲什麼 - 主要是因爲註冊表不像複製位於應用程序旁邊的配置文件（並且幾乎相同）。

如果你使用的是.Net2 +，你已經有了App.Config和User.Config文件，你不需要在註冊表中註冊DLL，所以遠離它。

配置文件有它們自己的問題（見下文），但這些可以編碼，你可以改變你的架構。

• 問題：應用程序需要可配置的設置。
• 解決方案：將設置存儲在Windows文件夾中的文件（WIN.INI）中 - 使用節標題對數據進行分組（Win3.0）。
• 問題：WIN.INI文件變得太大（並且變得混亂）。
• 解決方案：將INI文件中的設置存儲在與應用程序（Win3.1）相同的文件夾中。
• 問題：需要用戶特定的設置。
• 解決方案：將用戶設置存儲在用戶特定的INI文件中用戶的Window目錄（Win3.11）或應用程序INI文件中的用戶特定部分。
• 問題：安全 - 某些應用程序設置需要爲只讀。
• 解決方案：具有安全性的註冊表以及用戶特定和機器範圍部分（Win95）。
• 問題：註冊表變得太大了。
• 解決方案：用戶特定的註冊表移至用戶自己的「Application Data」文件夾中的user.dat，並且僅在登錄時（WinNT）加載。
• 問題：在大型企業環境中，您登錄到多臺計算機並必須設置EACH ONE。
• 解決方案：區分本地（本地設置）和漫遊（應用程序數據）配置文件（WinXP）。
• 問題：xcopy無法像.NET的其餘部分一樣部署或移動應用程序。
• 解決方案：APP.CONFIG XML文件與應用程序位於同一文件夾 - 易於閱讀，易於操作，易於移動，可跟蹤是否更改（.Net1）。
• 問題：仍然需要以類似（即xcopy部署）方式存儲用戶特定的數據。
• 解決方案：用戶本地或漫遊文件夾中的USER.CONFIG XML文件和強類型（.Net2）。
• 問題：CONFIG文件區分大小寫（對人不直觀），需要非常特定的打開/關閉「標籤」，連接字符串不能在運行時設置，安裝項目不能寫入設置（與註冊表一樣容易），無法輕鬆確定user.config文件，並且在安裝每個新修訂版時都會暴露用戶設置。
• 解決方案：使用ITEM成員在運行時設置連接字符串，在安裝程序類中編寫代碼以在安裝期間更改App.Config，並在未找到用戶設置時將應用程序設置用作默認值。

Answer 13

在.NET中確實沒有任何需要。

這裏有兩個例子展示瞭如何使用Project proerties來做到這一點。

這些示例通過Windows用戶項目屬性完成此操作，但Application也可以完成相同的操作。

這裏更多：

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

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

Answer 14

（晚的討論，但）簡短的回答：組策略。

如果您的客戶的IT部門想要強制執行Windows或您正在編寫或捆綁的組件（如鏈接速度，自定義錯誤消息或要連接的數據庫服務器）的相關設置，這仍然通常通過組策略來完成，這使得它的最終表現形式是存儲在註冊表中的設置。這些策略從Windows啓動或用戶登錄時開始執行。

有一些工具可用於創建自定義ADMX模板，以將組件的設置映射到註冊表位置，併爲管理員提供通用接口以實施策略s）他需要強制執行，同時只向他們顯示那些有意義的設置來執行這種方式。