Although you have been warned that accessing the registry can lead to system instability, you need to store and retrieve values in one or more of the registry hives.
Use the registry features in the My.Computer. Registry object to read, write, and otherwise manipulate registry information.
The My.Computer.Registry object includes the following members:
Most of the Registry members return a RegistryKey object, a generic object that can refer to any key within the registry. This object also has many useful members. Some members let you manipulate the keys that appear just below the one represented by the RegistryKey object:
Other members focus on the values tied to the active key:
Using any of the registry-related members is simple. For instance, you can display the \\HKEY_CURRENT_USER\Environment\TEMP value (Environment is a key, TEMP is a value) using the following statement:
MsgBox(My.Computer.Registry.GetValue( _ "HKEY_CURRENT_USER\Environment", "TEMP", ""))
On our system, this statement displays the following result:
C:\Documents and Settings\Administrator\Local Settings\Temp
But if you use the RegEdit application to view that same value, you see something a little different:
The GetValue() method performs some basic environment variable substitution on the stored registry value before returning it back to you. To get the unexpanded version, you need to go through one of the exposed RegistryKey objects:
Dim envKey As Microsoft.Win32.RegistryKey = _ My.Computer.Registry.CurrentUser.OpenSubKey( _ "Environment", False) MsgBox(envKey.GetValue("TEMP", "", _ Microsoft.Win32.RegistryValueOptions. _ DoNotExpandEnvironmentNames)) envKey.Close( )
The DoNotExpandEnvironmentNames flag prompts the GetValue() method to return the original unexpanded version of the value.
The Windows registry combines a machine-and user-specific hierarchical database of text, numeric, and binary values for use by both the operating system and applications installed on the local system. The hierarchy is akin to the directory/file structure used in the Windows file system, in which keys parallel directories, and values are similar to files. However, the registry is much more limited in what it can store at each hierarchy level.
Keys are named branches, all starting from a limited set of top-level keys known as hives. Each key can include any number of subkeys, plus zero or more values. Each value can store basic data values or can simply exist without data. Each key has a default value that includes no specific name. Figure 2-8 shows some of the components of the registry as viewed through the RegEdit application included with Windows.
Figure 2-8. RegEdit and the parts of the registry
Users needing access to the registry must be authorized through Windows. Normally, a user has full read/write access to all hives associated with the active user account, plus at least read access to most of the system hives. However, an administrator can place restrictions on portions of the registry, so error handling is recommended when using the various registry features of .NET.
The focus on the Windows registry has changed over the years. Originally, it was designed to support the Object Linking and Embedding (OLE) features of Windows and to provide central access to common system settings. For a while, Microsoft encouraged software developers to use the registry for application-specific settings as well. Unfortunately, this led to "registry bloat" that in some cases reduced overall application and system performance. Microsoft now recommends that applications store system-wide and user-specific settings in separate configuration files in the standard file system. With .NET's limited dependence on OLE/ActiveX components, even Microsoft is getting in on the separate-configuration-file act.