In addition, individual applications may require different settings specific to that program. For example, many applications require some version checking or that specific DLLs be available. These actions may vary from one installation to the next, and it's not a good idea to hard-code the settings into your application. Instead, you store values in a secondary file that accompanies the application.
During the early days of Windows, .INI files worked quite well; there is even a set of Windows API functions for managing configuration parameters. Now that we are a few years into the new millennium, XML is the way to go. .NET depends upon XML files (Machine.Config and Web.Config) for its configuration.
A name/value pair in Win.INI that turns on OLE messaging looks like:
OLEMessaging=1
The second way in which applications have configured themselves in the past is through the Registry. The Registry is a centralized database applications may use to store name/value pairs. The reason ASP.NET doesn't use the registry to configure information is because global nature Registry is in direct conflict with ASP.NET's need for flexibility during deployment. Settings stored in the Registry would need to be copied through the Registry API, whereas Configuration files may simply be copied.