he INI (application INItialization) file format became popular because it provided a convenient way to store values that might change (such as file locations, user preferences, etc.) in a standard format accessible to but outside of compiled application code. INI files are text-based, meaning you can read and change the values easily; logically arranged, meaningit is easy even for non-technical personnel to understand the contents; and the functions for reading and modifying the files were built into Windows.
In a recent featured discussion on DevX (see Use COM Interop to Read and Write to INI Files with .NET
) I explained how to read and write INI files with .NET using DllImport
to access the Windows API functions from within a C# or VB.NET class. Although the DllImport method lets you use existing INI files from .NET, it doesn't do anything to solve the problems inherent in the INI file format itselfand INI files have a number of deficiencies. For example, total file size is limited to 64Kb total, individual values cannot exceed 256 characters, and the Windows API provides no programmatic way to read and write comments. Translating the files to XML solves these problems.
The Ubiquitous INI File
An INI file has three types of information: sections, keys, and values. A section is a string enclosed in square brackets. The keys and values are paired. A key does not have to have a value, but when present, an equals (=) sign separates the key from the value. The keys and values together create an item
. The items are always "children" of a section header. Each section can have any number of child items. For example, here's a simple INI file structure:
INI files first appeared in Windows 3.x, and were originally intended to hold global Windows settings for various applications. Therefore, the section
items of the INI file format were initially called application
a name that persists in the Win32 API function calls to this day, even though the later documentation uses the section/key/value
terminology. Windows provides special APIs to read and write the win.ini
file in the $Windows
folder, as well as functionally identical "private" versions that read and write values from named INI files specific to one application. Windows provides a number of functions in kernel32.dll
to read and write INI filesall of which are marked as obsolete ( http://msdn.microsoft.com/library/default.asp?url=/library/en-us/win32/obsol_044z.asp
Microsoft began calling the API functions obsolete seven years ago
with the release of Windows 95, when it began touting the Registry as the perfect place to store application-level settings. The current MDSN documentation states that the functions are supported only for backward compatibility with Win16. Nevertheless, INI files have remained popular among developers, partly because Microsoft never made the Registry easy to use programmatically, and partly for many of the same reasons that XML became popular: INI files are easy to understand, easy to modify, either manually or programmatically, and you can simply copy them from one machine to another. Interestingly, despite Microsoft's insistence that INI files are obsolete, they're ubiquitous even in Microsoft software (search your local Documents and Settings folder\accountName
\Local Settings\Application Data folder for examples).
Why Not Use .NET Configuration Files?
.NET applications are supposed to use the AppSettings
section of configuration files to store key/value pair information. Unfortunately, the INI file format doesn't translate well to a simple list of key-value pairs, because you lose a "level" of information. Items in INI files exist as children of named sections; therefore many INI files repeat key names for each section. Any line in an INI file that starts with a semicolon is a comment. For example, the sample code uses this INI file:
; Company employees
If you were to remove the section names and try to place this information into a configuration file as key/value pairs, you would have duplicate key names. In other words, the default AppSettings
data provides no way to group the items into something equivalent to INI sections. You could
write a custom configuration handlerand I considered doing that for this article, but finally decided to do that in a later article, as simply translating the INI file to XML is both simpler to understand and easily extensible (more on extensibility