title: Visual Studio user Properties.Settings.Default file from multiple projects?
body: <p>So, despite a lot of info out there being difficult to understand and find on the latest Visual Studio settings file, I got that figured out.  On your executable project, right-click and select <code>properties</code>, then left-click on the <code>settings</code> tab on the left, create a settings file (if needed), and fill in some settings names, types, and values in the table.  If you want these to be permanent defaults that are embedded in the executable and read-only, set the scope to "application", but if you leave it at the default scope of "user", then you can save new values to a special user.config file in the system AppData folder which will be read from every time your app is launched, overriding the embedded defaults.  This basically allows every user to have a config file automatically stored by the system saving some config settings, such as last window location, etc.</p>
  
  <p>After setting up this, you can directly access the settings as follows:</p>
  
  <pre><code>var variable1 = Properties.Settings.Default.Variable1;
  var variable2 = Properties.Settings.Default.Variable2;
  </code></pre>
  
  <p>and so forth.  To set the properties to a new value is equally easy:</p>
  
  <pre><code>Properties.Settings.Default.Variable1 = variable1;
  Properties.Settings.Default.Variable2 = variable2;
  </code></pre>
  
  <p>And then, if you want to save the special user file with the current values into something like <code>C:\users\username\AppData\Local\ApplicationName.exe.xxxx\user.config</code>, then just use:</p>
  
  <pre><code>Properties.Settings.Default.Save();
  </code></pre>
  
  <p>Here is the issue - I'd like to access those same settings from all files in my solution, but the auto-generated methods are marked internal, so they can only be accessed from my main exe project.  I can create a class to essentially export the settings, but this only seems to work if the startup executable is always the same.  When I run unit tests (with xunit 2.0), I find that the settings are not set - if I use the library to set them and save, they show up in a Microsoft folder in <code>AppData</code>, that appears to correspond with Visual Studio.</p>
  
  <p>Does anyone know a way I can reliably access the <code>Properties.Settings.Default</code> values of a project across an entire solution, or am I stuck going with a straight file at a known location and all the I/O and parsing that entails?</p>
  
  <p>If so, is there a standard C# config file library that is used for this task outside of the built-in Visual Studio settings system?</p>
  
  <hr>
  
  <h2>Edit - Update:</h2>
  
  <p>The settings file appears to be based on the following:</p>
  
  <ol>
  <li><p>The Company Name in the Assembly Information (Properties/AssemblyInfo.cs or Project Properties/Application/Assembly Information/Company)</p>
  
  <ul>
  <li>If the Company is empty, it appears to use the Default namespace from (/Application/Default namespace), which matches the namespace used in Properties/Settings.settings/Settings.Designer.cs</li>
  </ul></li>
  <li><p>The Executable Name (i.e. app.exe)</p>
  
  <ul>
  <li>This is strictly the executable name at runtime, including extension, so if you rename the file, that will change the settings file name and location in AppData</li>
  </ul></li>
  <li><p>The Assembly version</p></li>
  </ol>
  
  <p>The folder within <code>AppData/Local</code> will be #1 above and then a nested folder will have the executable name (#2 above) with some other characters appended, and then a final nested folder will be the version (#3 above), and the file inside that will be user.config.</p>
  
  <p>So, what appears to be happening is that when the unit test runner executes, the company of the runner is used for #1 (the built-in VS runners will use "Microsoft", and the Resharper runner will use "JetBrains", etc.), the exe name will still start off with the Namespace of the tests, and then the version number is also from the test runner (I think).</p>
  
  <p>This means when running unit tests it will always look for and save to a different settings file than the main executable - so when you access the Properties.Settings.Default parameters from any assembly, it will look for the file in a different location (and save it to a different place) when running unit tests than from running the main executable.</p>