title: Alternatives to using web.config to store settings (for complex solutions)
body: <p>In our web applications, we seperate our Data Access Layers out into their own projects.</p>
  
  <p>This creates some problems related to settings. </p>
  
  <p>Because the DAL will eventually need to be consumed from perhaps more than one application, web.config does not seem like a good place to keep the connection strings and some of the other DAL-related settings.</p>
  
  <p>To solve this, on some of our recent projects we introduced a third project just for settings. We put the setting in a system of .Setting files... With a simple wrapper, the ability to have different settings for various enviroments (Dev, QA, Staging, Production, etc) was easy to achieve.</p>
  
  <p>The only problem there is that the settings project (including the .Settings class) compiles into an assembly, so you can't change it without doing a build/deployment, and some of our customers want to be able to configure their projects without Visual Studio.</p>
  
  <p>So, is there a best practice for this? I have that sense that I'm reinventing the wheel.</p>
  
  <p>Some solutions such as storing settings in a fixed directory on the server in, say, our own XML format occurred to us. But again, I would rather avoid having to re-create encryption for sensitive values and so on. And I would rather keep the solution self-contained if possible.</p>
  
  <p><strong>EDIT:</strong> The original question did not contain the really penetrating reason that we can't (I think) use web.config ... That puts a few (very good) answers out of context, my bad.</p>