AppSettings vs project-specific settings in Web.Config

Question

Okay, so this one has got me a bit confused. I have the following:

string csvOfAttributes = CableSolve.Web.Properties.Settings.Default.GenerateBoothReportAttributes;

and in my web.config:

<CableSolve.Web.Properties.Settings>
  <setting name="GenerateBoothReportAttributes" serializeAs="String">
    <value>327, 329, 330, 369, 342</value>
  </setting>
</CableSolve.Web.Properties.Settings>

I have two questions about this:

• If I omit my setting from the web.config file I receive compilation errors. How is this possible? Web.config is user-editable; I would only expect run-time errors. If I compile my application, deploy, then the user edits the name of this setting -- wouldn't that break the compiled code?
• I could potentially store this setting in the appConfig section of my web.config file. To access the values I would go through ConfigurationManager -- and I would only receive a null object at run-time if the setting is missing. This seems less advantageous as I tend to prefer my errors arising during compilation, but it leaves me wondering: what are the differences between these two options and when should I use them?

Answer 1

I think the answer is mostly contained in the question: the whole difference is the basic key-value pair schema verses more complex schemas. By extension, the difference relates to weakly-typed versus strongly-typed, and run-time versus compile-time. In general the latter is better, in the same sense that .NET is "better" than Javascript: you get alerted to errors early, rather than having them bubble into your application in unpredictable and hard-to-trace ways. Exceptions to the strong-schema preference might include:

• Your application requirements are evolving, so you don't want to lock in a schema
• You're working with a root-level configuration that different developers or applications will be using
• You want to allow "invalid" configurations and handle them at runtime