title: Windows Service, strange behaviour with appSettings in app.config
body: <p>I'm working on a project that has a shared core component which makes use of an <code>&lt;appSettings /&gt;</code> section in the corresponding configuration file.</p>
  
  <p>This works fine for the asp.net web part, which uses web.config.  </p>
  
  <p>However, there is a Windows service which uses this same shared core component, which (for various reasons) accesses configuration data directly from within (i.e. embedded calls to <code>ConfigurationManager.AppSettings["key"]</code>) which I can't easily refactor.</p>
  
  <p>This wouldn't be a problem but I am finding that the web service doesn't seem to be able to pick up the appSettings values that I have added to its app.config.  When I deploy this to a dev server, of course it becomes ServiceName.exe.config and the configuration file is otherwise operating correctly (it also contains some <code>&lt;applicationSettings /&gt;</code> typesafe settings which are working as expected.</p>
  
  <p>Since I can't easily change the shared component, I am stuck with somehow having to work with <code>&lt;appSettings /&gt;</code> in the Service's app.config file.</p>
  
  <p>Things I've checked: structure seems fine:</p>
  
  <pre><code>&lt;?xml version="1.0" encoding="utf-8" ?&gt;
  &lt;configuration&gt;
      &lt;configSections&gt;
          &lt;sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" &gt;
              &lt;section name="xxxxx.UploadManagerService.UploadManager" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" /&gt;
          &lt;/sectionGroup&gt;
      &lt;/configSections&gt;
      &lt;applicationSettings&gt;
          &lt;xxxxx.UploadManagerService.UploadManager&gt;
              &lt;setting name="NumberOfUploaderThreads" serializeAs="String"&gt;
                  &lt;value&gt;2&lt;/value&gt;
              &lt;/setting&gt;
               :
          &lt;/xxxxx.UploadManagerService.UploadManager&gt;
      &lt;/applicationSettings&gt;
  
    &lt;appSettings&gt;
      &lt;add key="keyname" value="value" /&gt;
       :
    &lt;/appSettings&gt;
  
  &lt;/configuration&gt;
  </code></pre>
  
  <p>(where : means 'more of the same' :-)</p>
  
  <p>Service runs okay except for where a method in the core component attempts to access any of the <code>&lt;appSettings /&gt;</code> values.</p>
  
  <p>Is there any way to get this to work properly with a Windows service?  I can't see any reason why it shouldn't just work, but it doesn't (throwing an exception when it tries to access any of the values).</p>
  
  <p>Here's a frag of the kind of place where it falls over:</p>
  
  <pre><code>return SendEmailViaAmazonSES(
            new List&lt;string&gt; { clientEmailAddress },
              ConfigurationManager.AppSettings["SalesEmail"],
              "Order Confirmation.",
              content);
  </code></pre>
  
  <p>...which is fortunately trapped in a try:catch and therefore nothing is falling over but those <code>ConfigurationManager.AppSettings["key"]</code> calls are used throughout and I can't change them without major impact to other systems which already use this core component.</p>
  
  <p>Any ideas?  </p>
  
  <p>Other things I've checked: service config file IS in same folder as service exe, dev config DOES contain the right values.</p>
  
  <p><strong>EDIT 25/5</strong></p>
  
  <p>Because the service only calls a few methods which require access to the <code>&lt;appSettings /&gt;</code> values, I've simply cheated by copying those methods into the service itself and using values in <code>&lt;applicationSettings /&gt;</code> instead.  It's not ideal and I'm still very keen to find out why this doesn't work for a Windows Service, but I couldn't afford to wait so I've taken the pragmatic decision to 'fudge it' in the meantime.  I can always return to this at some later point, or (as happens) forget all about it ;-)</p>