Alvin Toffler, in his groundbreaking book Future Shock, added the word "overchoice" to our vocabulary. The idea was that the sheer number of options that we now have makes life harder, not easier, because we have to spend precious time and energy just deciding which option to concentrate on before making any progress on the original problem. It gets worse if we happen to pick the wrong option and have to back up and try it again.

This is a problem that we see a lot in .NET as well as programming in general these days. There are a lot of good ideas built into .NET and more ideas that are just carried forward for compatibility's sake. In particular, there are a lot of methods to choose from if you need to save a little configuration data for your program.

This article will describe the various ways that this can be done, but we'll finish up with a very simple example - complete with the downloadable source - showing what I think is the easiest way to save a few data items between program executions: native XML.

From a historical perspective, configuration information used to be saved in simple text files. You may still see a file named "settings.txt" or "config.txt" even today. In their latest book (Visual Basic 2005 for Programmers, 2nd Edition, Paul J. Deitel, Harvey M. Deitel, ISBN: 0-13-225140-X), the Deitel Developer Series has a major section showing how to create and read what is actually a "comma separated value" (CSV) file - an idea that is decades old.

(Their goal is to demonstrate stream oriented sequential file processing, but the end result is the same.)

The next step up the ladder was to require some structure for configuration files. The best example is proably the .INI files. Here's what a typical .INI file looks like (from Wikipedia):

[section1]

; some comment on section1
var1 = foo
var2 = doodle

[section2]

; another comment
var1 = baz
var2 = shoodle

These types of files were very typical when Windows 3.1 was the hot OS, even though Windows itself used config.sys and autoexec.bat for most startup configuration.

Then the thinking shifted to another idea: Put all your eggs in one basket and then watch that basket !! The "basket" is the Windows registry and it's still used for most of the Windows OS information. The next version of Windows, Vista, will continue to use the registry in just about the same way. In the era of Windows 2000 and Windows NT, creating lots of little .INI files was discouraged and programmers were encouraged to put their own program configuration information in the registry too, but we have discovered now that stuffing everything into one basket has it's own set of problems. So while COM, the technology used in VB 6, required that DLL's be "registered" .NET does not. VB.NET does provide excellent support for saving configuration information in the registry using the My.Computer.Registry object that is new in Framework 2.0 if that's the way you want to go.

The idea of using individual configuration files - information that is only used by your program in a few small files in the program folder - gets a lot more respect these days, thanks in no small measure to .NET. After all, Visual Studio will create a couple of dozen different files for even the simplest Windows application filled with exactly this kind of information.

But there are still more options to be considered.

The new buzzword for writing a file these days is "persist" -- as in "Persisting an Object" or "Persist an ADO.NET DataSet" (titles taken directly from Microsoft's web site). I used to call it, "saving an object" or "writing a dataset" but I guess I'll have to catch up with the times and start saying "persist" now. The idea is that some result of the program lasts after the program stops running and is restored when the program starts up again. The dictionary definition of "persist" is "to exist in spite of adversity." Being removed from computer memory is an example of adversity, I suppose.

You can persist information in several formats, however. We started the article by considering CSV and INI files, but there are more formats available now. VB.NET has excellent objects that help you serialize data to binary files, SOAP files, or XML files. Serialization is just the process of converting an object into a linear sequence of bytes. You can read more about serialization in lesson 3 from an About Visual Basic email tutorial. Microsoft's own Visual Studio will save configuration data in binary, XML, and proprietary formats. You can find examples in Microsoft's MSDN web site about how to persist data in all of these formats.