title: Keep settings in sync between forms application and windows service (or any n-tier, really)
body: <p>I have a Windows Service that performs a number of periodic activities, and I want to change the settings of this service from a Windows Forms app. I'm not sure, though, about the best way to make sure the service has the most updated user preferences in it (how often to run, what folders to use for things, whatever else the user can specify). The user can change settings any time, at will, and I'd like the service know about it almost immediately. Here are the options I'm weighing:</p>
  
  <ol>
  <li>The form and service share use the same "Settings" object from a third, shared project, and the form uses a WCF "UpdateSettings(newSettings)" call to let the service know that there have been changes (or, optionally, a call to update each individual setting, though this seems like a lot over different calls). I currently use WCF for basic messages, but the settings object can be huge, since there's a lot of other stuff in there</li>
  <li>Form and Service use a common config file (XML, or the same settings object from #1, but serialized to disk). The Form just writes a new copy of the object after it's been changed, and the service checks every so often and picks it up if it's new, updating its copy of the settings</li>
  <li>Same as #2, but with a basic WCF call that that tells the service to go get the settings. Essentially, an "on-demand" instead of "polling" version of #2.</li>
  </ol>
  
  <p>I know best is subjective, but I'm interested in any obvious pro or con reasons for these choices. Since I'll have to save my settings between runnings of the application (reboots, etc), I'll have to serialize the settings to disk anyway, so I'm already leaning towards #2 or #3. I'll need a place on disk where I can save the settings, but maybe the AppData folder will work okay, though that will only allow Administrators to change the settings, since they're the only ones that have permission to write to this location (where every user, including the service account, can read it).</p>
  
  <p>Thanks for your insight!</p>