If you’ve been reading this column regularly, you know by now that we’ve moved far from the big city, way out into the country. Mostly to provide a moat between us and any noisy neighbors, we bought a big piece of land. There’s a huge relatively flat block of open space behind the house, and it’s very hot and sunny here for most of the year, as well. Because we’re running a few servers, and several other computers, our electric bill is high. Very high. Our neighbor’s bill is around $75 per month. Ours is generally $400 per month, or more. And that’s if we’re not running the air conditioning. (The problem is that PG&E charges a tiered rate, so that the more you use, the more you pay per kilowatt. So you just compound the problem if you use a lot of electricity.)
When we first moved in, we joked about putting in solar panels. After living here for two years, it finally rose to the top of the “real” stack, and we moved on it. Luckily, California was still (at the time) offering a substantial rebate on solar panel installations, and we figured that if we didn’t go for it then, we’d lose the rebate option. And so we did. I could never have imagined how complicated this process is. It seems that a huge proportion of homes in Germany have managed to install solar panels, but in the USA, the percentages are so low that there’s no easy pre-fab way to install the system. Each home requires unique planning and design, and ours was, of course, no different. If wanted to cover our entire electrical usage, we’d have to install 48 3x5 foot panels, and those wouldn’t fit on the roof. It quickly became clear that we’d need a 30x24 foot area in the back yard for the panels, and luckily, we had it.
I could never have imagined how the installation of the panels (much less the cost of the panels) could possibly cost as much as it did, before we started. Having seen the finished product, which finally came on line this very morning, I now understand. The infrastructure for the panels is a huge framework of steel, planted in concrete moorings five feet deep. The installers had to bring in heavy equipment just to get the steel frame onto the property, much less to hang the 48 panels. They ran a trench from the array to the house, and conduit from the far corner of the house around to the electrical panel. The system requires two electrical inverters (boxes about the size of a large desktop computer) which connect the grid to the house electrical system.
Everyone asks, so I’ll just answer before you do: We didn’t want (and you probably don’t either) a system that uses batteries for power storage. That is, we’re not off the grid. At night, and on rainy days, we generate little or no electricity, and have to use PG&E’s power. On the other hand, on sunny days, we generate far more than we use, push it back up to the power grid and receive credits on our bill. The goal is to end up with the smallest bill possible (PG&E charges you just to be connected and send you a bill, so you’re paying somewhere around $12 per month for the privilege of sipping on the power grid when you need it). I’ll report in, in a year.
The configuration of the system took far more effort than I could possibly have imagined. It does, however, provide a cool Web-based interface for monitoring the two inverters, keeping track of how much carbon dioxide we’ve spared Nevada County, and how much energy we’ve generated. The configuration effort really surprised me-if it takes this much effort for each home that installs solar panels, how many homes will bother?
Speaking of configuration, a friend recently came to me with this question: “I need to be able to read and manipulate information in an application’s configuration file (not the current application, which is a Windows service). I can’t find a way to do that. I’ve found the System.Configuration.Configuration class, but I can’t get code that uses this class to compile. What’s up?”
Let’s get it out of the way now: The System.Configuration.Configuration class (along with its friend, the System.Configuration.ConfigurationManager class) will send you down an ugly rabbit hole that can consume hours of your life. Here’s the biggest problem: it’s just plain confusing. To top it off, for reasons that aren’t completely clear to me, even if you add an Imports/using statement for the System.Configuration namespace to your file, the code you write simply won’t compile.
For example, after adding the necessary imports/using statement, the following (which looks like it ought to work), causes compilation errors:
[Visual Basic]
Dim config As Configuration = _
ConfigurationManager.OpenExeConfiguration( _
"C:\Temp\SomeApplication.exe")
[C#]
Configuration config =
ConfigurationManager.OpenExeConfiguration(
@"C:\Temp\SomeExecutable.exe");
This code, which should return a reference to the app.config file associated with the named application, goes nowhere. Although I’ve been down this path several times, I never seem to be able to remember the solution. Let’s clear it up, because it’s very simple: Even though the project template appears to include information about the System.Configuration namespace, it does not include a reference to the System.Configuration assembly, which is required in order to use this functionality. Clearly, some of the System.Configuration namespace exists within an assembly that is referenced by default, but the part you need for this code is not. Therefore, in order to do this work with configuration files, you must explicitly reference the System.Configuration assembly.
Once you add the necessary reference, the code works as you might expect. I wrote the following procedures to demonstrate the functionality for my friend. This code opens an existing configuration file, adds a new setting, sets a value, and displays the files contents before and after making the change:
[Visual Basic]
' Open app.config of executable
Dim config As Configuration = _
ConfigurationManager.OpenExeConfiguration( _
"C:\Temp\SomeApplication.exe")
' Add an application setting
config.AppSettings.Settings.Add( _
"ModificationDate",
DateTime.Now.ToLongTimeString())
' Save the configuration file
config.Save(ConfigurationSaveMode.Modified)
' Force a reload of a changed section
ConfigurationManager.RefreshSection("appSettings")
[C#]
// Open app.config of executable
Configuration config =
ConfigurationManager.OpenExeConfiguration(
@"C:\Temp\SomeApplication.exe");
// Add an Application Setting
config.AppSettings.Settings.
Add("ModificationDate",
DateTime.Now.ToLongTimeString());
// Save the configuration file
config.Save(ConfigurationSaveMode.Modified);
// Force a reload of a changed section:
ConfigurationManager.
RefreshSection("appSettings");
It’s again a long stretch from solar configuration to configuration files, but you get the idea: both are a lot more complex than you would at first imagine. In both cases, there are tricks involved (in the case of configuration files, setting the reference you need, even though it appears that you shouldn’t need to when the Imports/using statement works, you normally assume you don’t need to add a reference). Take a look at the documentation for the System.Configuration.Configuration class-you’ll find full support for reading and writing configuration files there. Just don’t forget to add that reference first. And check out solar power, if you’re so inclined. Depending on where you live, it could save you a lot, in the long run.