Using Environmental Variables

It would be nice if the world were confined to standard file locations. However, in rare cases, you need to rely on a custom file location.

The reasons to use a custom file location become less with every version of Windows, but some applications still seem to need them. For example, you'll find that SQL Server still requires a special location to store libraries, which you can find in the lib environmental variable.

It turns out that you'll find some helpful user information even if you don't create your own environment variables. The ALLUSERSPROFILE environmental variable points to the location of the folder that contains data for all users on the system. The TEMP environmental variable tells you the location of temporary files on the system, which can be important information when you want to create temporary data.

Reading environmental variables means looking at key/value pairs. The key tells you which environmental variable you're looking at, while the value tells you the information the entry provides. Building on the example shown in Listing 1, here's the technique you use to fill a combo box with environmental value key entries.

// Read the list of environmental variables.
foreach (String KeyName in 
   Environment.GetEnvironmentVariables().Keys)
{
   cbEnvVariable.Items.Add(KeyName);
}

// Choose the first item in the list.
cbEnvVariable.SelectedIndex = 0;

Because the environmental variables appear as part of a collection, you use a different method to fill the combo box, cbEnvVariable, with data. However, the principle is the same. You use a technique such as this one to avoid hard coding any values and tying yourself to a particular operating setup. The resulting list is completely flexible and reflects any changes in the environmental variable list every time you start the application.

Notice that the information you need is stored in the Keys property of the IDictionary object returned by the Environment.GetEnvironmentVariables() method. The Keys object itself is of type IDictionary. Each member is a string containing one key name. Here's the code you use to remove a single value from the environment variables.

private void btnGetEnvVariable_Click(object sender, 
                                     EventArgs e)
{
   // Display the environmental variable content.
   MessageBox.Show(
      Environment.GetEnvironmentVariable(
         cbEnvVariable.Text));
}

As you can see, all you need is the name of an environmental variable as the input to the Environment.GetEnvironmentVariable() method. The resulting string contains the environmental variable value. You use the Environment.SetEnvironmentVariable() method to create new environmental variables of your own. You could perform this task as part of a setup program or in response to user changes. The idea is to keep your application data location information flexible, so it can respond to future operating system changes.

Gone are the days when you should even consider hard-coding paths in your application. Any hard coding you perform is an invitation to disaster later. Microsoft has proven that it'll move things around at its convenience, not yours. Consequently, flexible code that can adapt to any change in application environment is the rule of the day.

Many developers today rely on techniques that are almost certain to cause massive problems in the future. Hard-coding directory information in an application is only the tip of the iceberg. You'll also experience problems from hard-coding the information in the registry or using configuration files to perform the task. Generally, what you should store are relative, not absolute, directory paths. To avoid potential problems, save only the relative path information for your application, and then create a full path to the data on the fly each time the application starts.