App.config and disk I/O

[mickieparis]

Hello, I have a custom exception class that contains a mail handler
class and when an error happens I get an email. In my mail handler
class I pull values from the app.config.

Example:
private void LoadConfiguationSettings() {
this.MailTo = ConfigurationManager.AppSettings["EmailTo"];
this.MailFrom = ConfigurationManager.AppSettings["EmailFrom"];
this.SMTPServer = ConfigurationManager.AppSettings
["SMTPServer"];
}

My question is, does .net need to do a disk I/O to pull these values
every time I instantiate these classes or are the values in app.config
cached? I’d like to avoid as much disk I/O as much as possible.
Thanks
MP

 

[Omatase]

In my experience (at least with class libraries) the config file isn't
even consulted at runtime. I've had to implement my own custom
configuration objects because the config settings were compiling into
the code. Still haven't figured out the point in that.

If it is a WPF or Forms app I'm not sure if they have the same
behavior or not.

 

[Peter Duniho]

Hello, I have a custom exception class that contains a mail handler
class and when an error happens I get an email. In my mail handler
class I pull values from the app.config.

Example:
private void LoadConfiguationSettings() {
this.MailTo = ConfigurationManager.AppSettings["EmailTo"];
this.MailFrom = ConfigurationManager.AppSettings["EmailFrom"];
this.SMTPServer = ConfigurationManager.AppSettings
["SMTPServer"];
}

My question is, does .net need to do a disk I/O to pull these values
every time I instantiate these classes or are the values in app.config
cached? I’d like to avoid as much disk I/O as much as possible.

You could look at the specific implementation in Reflector for
ConfigurationManager to see. Or you could use the Designer-provided
Settings class instead, and look at that implementation instead.

But even if both implementations always used disk i/o functions, a) that
does not mean that actual disk i/o happens when they are called (Windows
caches disk data), and b) that does not mean that if you attempt to
cache the values yourself that actual disk i/o would _not_ happen
(everything you keep in memory has the possibility of being swapped to
disk if the system needs the physical RAM for something else…the
likelihood of that happening goes up dramatically the longer an
in-memory data structure sits around unused).

IMHO, you should instead of trying to avoid disk i/o per se, design your
code so that if you have some specific reason for trying to avoid disk
i/o, you address that reason instead. For example, don't put things
that might need to perform disk i/o in critical paths.

I also would not put a mail handler _inside_ an exception class. IMHO
exception classes should be lightweight representations of particular
kinds of errors. The code handling the exception should in control of
what to do in response to the exception, such as sending email.

Pete

 

[Arne Vajhøj]

Hello, I have a custom exception class that contains a mail handler
class and when an error happens I get an email. In my mail handler
class I pull values from the app.config.

Example:
private void LoadConfiguationSettings() {
this.MailTo = ConfigurationManager.AppSettings["EmailTo"];
this.MailFrom = ConfigurationManager.AppSettings["EmailFrom"];
this.SMTPServer = ConfigurationManager.AppSettings
["SMTPServer"];
}

My question is, does .net need to do a disk I/O to pull these values
every time I instantiate these classes or are the values in app.config
cached? I’d like to avoid as much disk I/O as much as possible.

They are cached.

If you need to force a read from disk use RefreshSection call.

http://msdn.microsoft.com/en-us/library/system.configuration.configurationmanager.aspx

Read a section from a configuration file. To access configuration
information, call the GetSection method. For some sections such as
appSettings and connectionStrings, use the AppSettings and
ConnectionStrings classes. These members perform read-only operations,
use a single cached instance of the configuration, and are multithread
aware.

http://msdn.microsoft.com/en-us/lib...tion.configurationmanager.refreshsection.aspx

Arne

 

[Arne Vajhøj]

In my experience (at least with class libraries) the config file isn't
even consulted at runtime. I've had to implement my own custom
configuration objects because the config settings were compiling into
the code. Still haven't figured out the point in that.

????

Can you post a simple example demonstrating that?

I have never seen an app.config being compiled
into the executable.

Arne

 

[Arne Vajhøj]

Hello, I have a custom exception class that contains a mail handler
class and when an error happens I get an email. In my mail handler
class I pull values from the app.config.

Example:
private void LoadConfiguationSettings() {
this.MailTo = ConfigurationManager.AppSettings["EmailTo"];
this.MailFrom = ConfigurationManager.AppSettings["EmailFrom"];
this.SMTPServer = ConfigurationManager.AppSettings
["SMTPServer"];
}

My question is, does .net need to do a disk I/O to pull these values
every time I instantiate these classes or are the values in app.config
cached? I’d like to avoid as much disk I/O as much as possible.

You could look at the specific implementation in Reflector for
ConfigurationManager to see. Or you could use the Designer-provided
Settings class instead, and look at that implementation instead.

Reading the docs is actually sufficient in this case.

And information revealed by reflector is not a good
guidance for design anyway, because it could change
in next version of .NET.

Arne

 

[Peter Duniho]

[...]

You could look at the specific implementation in Reflector for
ConfigurationManager to see. Or you could use the Designer-provided
Settings class instead, and look at that implementation instead.

Reading the docs is actually sufficient in this case.

IMHO, the docs are not really clear. Just because there's a
RefreshSection() method, that does not necessarily imply that
invalidation of the cache never happens on its own. And of course, the
cache has to be populated at some point; if it happens on the first
access, that doesn't necessarily address the OP's issue without more
effort on their part.

I just don't see anything in the docs that provides a hard and fast
contract Microsoft is required to follow that would ensure the behavior
the OP seems to be looking for. That could just be a doc bug (it'd sure
be nice if somewhere there was a detailed specification for _all_ of the
..NET API), but it's a problem nonetheless.

And information revealed by reflector is not a good
guidance for design anyway, because it could change
in next version of .NET.

That's absolutely true, I agree 100%. Dependence on implementation
details is an awful way to write one's own code.

But given the question, it's the most reliable way to obtain an answer.

My personal opinion is that the OP should not depend on this kind of
implementation detail, even if the docs do provide at least a partial
implication of caching behavior. But if they insist, they may need to
examine the implementation specifics to know for sure what's going to
happen.

Pete

 

[mickieparis]

So it looks like as long as one uses the AppSettings, it gets cached.
And Pete, thanks for the design tip. I have another design question
regarding circular references between projects, I'll post a separate
thread for that.

Thanks All,
MP

 

[Jeff Johnson]

????

Can you post a simple example demonstrating that?

I have never seen an app.config being compiled
into the executable.

I can tell you that on one occasion (and admittedly, ONLY one occasion) I
have definitely found "phantom settings values" in a compiled EXE. Even
though I explicitly changed values in the xxx.config file (on a DIFFERENT
machine), the executable was still using the values in the Settings file on
my development machine. I had to change my local Settings file to the
desired values, recompile, and put the new EXE on the target machine before
it worked. It was weird.

 

[Peter Duniho]

I can tell you that on one occasion (and admittedly, ONLY one occasion) I
have definitely found "phantom settings values" in a compiled EXE. Even
though I explicitly changed values in the xxx.config file (on a DIFFERENT
machine), the executable was still using the values in the Settings file on
my development machine. I had to change my local Settings file to the
desired values, recompile, and put the new EXE on the target machine before
it worked. It was weird.

The default settings are hard-coded in the program, if one uses the
Designer-provided Settings class. But, if there exists a proper
app.config file in the proper location, it will be used instead of the
hard-coded defaults (and when the app.config file doesn't exist, it'll
be created when the program is run, using the defaults hard-coded in the
code).

There also is the slightly confusing behavior that when running under
the debugger, one is actually executing a different .exe than the one
that would actually be deployed (VS adds the "*.vshost.exe" and runs
that instead of yours directly).

It's true that sometimes the behavior may seem non-intuitive, but that's
always just going to be because of some overlooked aspect of how the
configuration stuff works. It doesn't just mysteriously pull settings
from arbitrarily different places than normal.

Pete

 

[Jeff Johnson]

The default settings are hard-coded in the program, if one uses the
Designer-provided Settings class. But, if there exists a proper
app.config file in the proper location, it will be used instead of the
hard-coded defaults (and when the app.config file doesn't exist, it'll be
created when the program is run, using the defaults hard-coded in the
code).

There also is the slightly confusing behavior that when running under the
debugger, one is actually executing a different .exe than the one that
would actually be deployed (VS adds the "*.vshost.exe" and runs that
instead of yours directly).

It's true that sometimes the behavior may seem non-intuitive, but that's
always just going to be because of some overlooked aspect of how the
configuration stuff works. It doesn't just mysteriously pull settings
from arbitrarily different places than normal.

Yeah, I know, but I swear to you that the app was, for example, called
MyApp.exe and in the same folder was MyApp.exe.config whose values had been
changed from the app.config file on my development box, yet the application
(which was running on a completely different box) was executing with the
same values that were in my local app.config instead of the changed values
in MyApp.exe.config. And again, this was basically a one-time fluke, but I
DID see it happen.

 

[Adam Clauss]

And again, this was basically a one-time fluke, but I
DID see it happen.

And how early into the morning was this?

-Adam

 

[Jeff Johnson]

And how early into the morning was this?

The WHOLE morning, actually! It was a pull-your-hair-out experience.