Dynamic Debug Code Management with BooleanSwitches
- Defining the XML Switch
- Adding the BooleanSwitch to Code
- Managing Debug Code with the BooleanSwitch
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
As languages go, I love C++. As development environments and productivity tools go, I have had a great deal of productive good fun working with Borland's Delphi. I am the opposite of a language bigot; I like all great languages and tools. As great languages and tools go, there is no greater support for debugging and testing code then Microsoft's .NET Framework. The System.Diagnostics namespace in .NET has more classes and code for helping you debug and test your applications than any other tool by a mile.
One of the benefits of being the latest and greatest tool is that you have the opportunity to leapfrog over the competition (at least for a short time). Microsoft has clearly done that. The "Softies" have taken techniques that you and I have been using for years, extending them, and incorporating them into .NET. Because the debugging tools in .NET could easily take up the pages of an entire book, we'll have to limit our discussion to an appetizer. What I want to talk about in this article is the BooleanSwitch.
A BooleanSwitch is the notion of externalizing a value that can be read and used to decide whether some chunk of code should run. This is not a new concept; you can easily implement it with an .INI file (or any kind of file). What is new is that Microsoft has recognized it as a valid debugging-and-testing strategy and has made it part of .NET using XML as the storage medium. The benefit is that this old standby is now and forever part of a common toolset. We can move on to other things.
This really is what the role of mainstream companies is: Identify what works and make it ubiquitous. (Gutenberg and the Bible/printing, Ford and the automobile, Gates and the BooleanSwitch, and on it goes—stretching forward and backward in time.) Making something part of the common vernacular permits us to proceed to the next thing. This is progress.
Defining the XML Switch
XML is a self-describing, text-based language. It is ideal for simple tasks such as storing configuration information and complex tasks such as transporting the description and data that describes an object as text across the Internet. Instead of each programmer figuring out how to store external configuration information, we can all settle on the public standard, XML.
.NET supports an application configuration file for executables. Such a file has the same name as your executable assembly with a .config extension. Placed in the same directory as an executable named HasBooleanSwitch.exe, the application configuration file would be named HasBooleanSwitch.exe.config.
TIP
There is a machine.config file that serves a similar purpose as the application configuration file, but on a larger scale. Technically, you could put switch information in the machine.config file, located in <installdrive:>\\winnt\Microsoft.NET\Framework\<version>\\CONFIG, where <installdrive> is the drive that Windows was installed on and <version> is the version number of the .NET framework you are configuring. However, it is a better practice and not especially difficult to define a configuration file for each application.
The configuration file needs to contain well-formed XML, and the BooleanSwitch class will be looking for a specific tag as well as specific attributes for that tag. Listing 1 contains contents of a configuration file that has information relevant to only our switch in it.
Listing 1: An Application Configuration File Defining a BooleanSwitch.
1: <?xml version="1.0" encoding="utf-8" ?> 2: <configuration> 3: <system.diagnostics> 4: <switches> 5: <add name="MySwitch" value="1" /> 6: </switches> 7: </system.diagnostics> 8: </configuration>
Don't use line numbers in your XML document. Line numbers were added for reference. The first statement—line 1—is required for an XML document. The version attribute indicates the version of XML and the second attribute, encoding, is optional. The encoding attribute indicates how the text is encoded. UTF-8 is a Unicode encoding.
Line 2 starts a <configuration> block ended by the </configuration> tag. Tags in configuration files are case-sensitive. The <configuration> tag indicates that information in this section is application configuration information.
The <system.diagnostics> tag—opened on line 3 and closed on line 7—contains information that is relevant to .NET classes in the System.Diagnostics namespace. We will define our BooleanSwitches in this section—between the opening and closing <system.diagnostics> tags.
The <switches> tag contains our BooleanSwitches. In our example, we have added a switch named MySwitch with a value of 1. For BooleanSwitches, the value is treated very simply as a Boolean value. Any non-zero value is treated as True, and 0 is treated as False. Listing 1 defines a switch named MySwitch that is enabled.
TIP
Other configuration tags include the <remove> and <clear> tags, which can be used to remove individual switches or to clear all switches.
Ending tags can be abbreviated to /> as in <clear />, which becomes the complete element for the clear tag.
The benefit of using XML is that the syntax for defining the switch becomes a standard that can be codified. This standard is codified in the System.Diagnostic.BooleanSwitch class.