Siphon Configuration

claco — Mon, 16 Mar 2009 02:53:49 +0000

This is the second in a series of posts about Siphon, a set of data monitoring utilities for .NET under the MIT license. The source code can be found on GitHub.

Introduction

In this article, I’m going to cover how Siphon configuration works, the options and how to use the configuration classes to read/write configuration information.

Configuration Section

Here’s a sample Siphon configuration section from the source code:

Let’s break this down piece by piece. First, we need to tell .NET who’s in charge of the siphon configuration section:

Next, we add a new monitor element to the monitors collection:

Here we have a monitor named IntervalMonitor and told Siphon what type to load. If you’re not familiar with using type strings in .NET configuration, the string above tells .NET that we want to use the class ChrisLaco.Siphon.LocalDirectoryMonitor in the Siphon assembly. Note that if you want to use types that are installed into the GAC you will need to use the full type string including the Culture, PublicKeyToken and Version.

Next, we configure setting required by the LocalDirectoryMonitor:

The settings consist of name/value pairs that are passed to the monitors Initialize() method. The number of options and their values vary depending on the monitor being used. Next, we’ll tell the monitor how often to look for new data:

Just like with the monitor element above, we need to tell Siphon what schedule class we want to use. In our case, we’re going to use the IntervalSchedule, and set the interval using a string TimeSpan.Parse() understands: 1 day, 2 hours, 3 minutes and 4 seconds. If you are interested in a daily schedule, you can also use the daily element to specify a daily schedule:

Note: whether you use an interval or a daily schedule, the schedule type you use must understand the configuration you’ve chosen. As we’ll see in the Configuration classes later, the configuration format is setup to handle the most common use cases, like daily schedule values. Just like the monitor element, the schedule element also has a settings element used to pass name/value options to the specified schedule type.

Now that we’ve chosen a monitor and a schedule, the last thing to do is to tell Siphon who will process the newly found data as it arrives:

Here we’ve loaded the DummyProcessor, which does does nothing with new data and always returns True. As with the monitor and schedule elements, the processor element also has a settings element collection.

Reading Configuration

Siphon comes with a set of classes to read/write siphon configuration data. Once you have finished setting up your app.config, you can use the SiphonConfigurationSection class to load the section and loop through all of the configured monitors:

REM Load config section: defaults to 'siphon'
Dim section As SiphonConfigurationSection = SiphonConfigurationSection.GetSection

REM Loop through monitor elements
For Each monitor As MonitorElement In section.Monitors

    REM Get a setting
    Dim path As String = monitor.Settings("Path").Value

    REM create an instance of the specified type
    Dim instance As IDataMonitor = monitor.CreateInstance
    instance.Path = path

    REM Set the schedule
    instance.Schedule = monitor.Schedule.CreateInstance

    REM Set the processor
    instance.Processor = monitor.Processor.CreateInstance

    REM Process new data
    instance.Process()
Next

The code above is pretty straight forward. One item of interest: when CreateInstance is called, it creates an instance of the specified type and calls the Initialize() method on the new instance. While we set the Path setting manually, the monitors Initialize() could have also done the same thing.

All monitors must implement the IDataMonitor interface. All schedules must implement the IMonitorSchedule interface and all processors must implement the IDataProcessor interface. CreateInstance() looks for a constructor with no parameters in the type being created.

Writing Configuration

You can also use the configuration classes to programaticaly create configuration files. SImply create the settings in code, then save the config to the specified file:

Dim config As Configuration = ConfigurationManager.OpenExeConfiguration("C:\Path\To\SomeApp.exe")
Dim section As New SiphonConfigurationSection
Dim monitor As New MonitorElement("TestMonitor", "LocalDirectoryMonitor, Siphon")

monitor.Settings.Add(New NameValueConfigurationElement("Path", "C:\"))
monitor.Processor = New ProcessorElement("MockProcessor, SiphonTests")
monitor.Processor.Settings.Add(New NameValueConfigurationElement("Foo", "Bar"))
monitor.Schedule.Type = "IntervalSchedule, Siphon"
monitor.Schedule.Daily.Add(New TimeElement(New TimeSpan(100)))
monitor.Schedule.Daily.Add(New TimeSpan(200))
section.Monitors.Add(monitor)

config.Sections.Add("siphon", section)
config.Save()

This will update the app.config file for the specified executable path with the new configuration information. The code above will generate something like this:

Always Set Application Name In SqlClient Connection Strings

claco — Sat, 14 Feb 2009 04:05:21 +0000

If you’re using connection strings on the web, set Application Name to the domain name. If you’re using connection strings with an executable, set Application Name to the executable name. If you have to use SQL Profiler to diagnose performance issues, it will be easier to filter out a specific application or web site.

ConfigurationElementCollection Gotcha

claco — Sun, 02 Nov 2008 04:03:34 +0000

Here’s a fun way to waste 2 hours of your life. I was writing a custom config section, and trying to figure out why this wasn’t throwing a duplicate key error:

After surfing Google endlessly, I finally found this on MSDN:

Note that elements with identical keys and values are not considered duplicates, and are accepted silently. Only elements with identical keys but different values are considered duplicates.

That was fun. :-/