因此，尽管在最新的Visual Studio设置文件中有很多信息很难理解和找到，但我还是弄清楚了。在可执行项目上，右键单击并选择properties，然后左键单击左侧的settings选项卡，创建一个设置文件(如果需要)，并在表中填写一些设置名称、类型和值。如果您希望这些是嵌入可执行文件中的永久默认值，并且是只读的，请将作用域设置为"application"，但如果将其保留在默认作用域"user"，则可以将新值保存到系统AppData文件夹中的一个特殊user.config文件中，该文件将在每次启动应用程序时读取，从而覆盖嵌入的默认值。这基本上允许每个用户都有一个由系统自动存储的配置文件，保存一些配置设置，如最后一个窗口的位置等。
设置后，您可以直接访问以下设置：
var variable1 = Properties.Settings.Default.Variable1;
var variable2 = Properties.Settings.Default.Variable2;
等等。将属性设置为新值同样容易：
Properties.Settings.Default.Variable1 = variable1;
Properties.Settings.Default.Variable2 = variable2;
然后，如果您想将具有当前值的特殊用户文件保存到类似C:usersusernameAppDataLocalApplicationName.exe.xxxxuser.config的文件中，那么只需使用：
Properties.Settings.Default.Save();
问题是，我想从我的解决方案中的所有文件中访问这些相同的设置，但自动生成的方法被标记为内部方法，因此只能从我的主exe项目中访问它们。我可以创建一个类来导出设置，但这似乎只有在启动可执行文件始终相同的情况下才有效。当我运行单元测试(使用xunit 2.0)时，我发现设置没有设置——如果我使用库来设置和保存它们，它们会显示在AppData中的Microsoft文件夹中，该文件夹似乎与Visual Studio相对应。
是否有人知道我可以在整个解决方案中可靠地访问项目的Properties.Settings.Default值的方法，或者我是否一直在使用位于已知位置的直接文件以及所需的所有I/O和解析？
如果是，在内置的Visual Studio设置系统之外，是否有用于此任务的标准C#配置文件库？
编辑-更新：
设置文件似乎基于以下内容：
程序集信息(Properties/AssemblyInfo.cs或Project Properties/Application/Assembly Information/Company)中的公司名称
- 如果公司为空，则它似乎使用来自(/Application/Default namespace)的Default命名空间，该命名空间与Properties/Settings/Settings.Designer.cs中使用的命名空间匹配
可执行文件名(即app.exe)
- 这是运行时严格的可执行文件名，包括扩展名，因此如果重命名文件，将更改设置文件名和AppData中的位置
程序集版本
AppData/Local中的文件夹将位于上面的#1，然后嵌套文件夹将具有附加了一些其他字符的可执行文件名(上面的#2)，然后最终嵌套文件夹将为版本(上面的#3)，其中的文件将为user.config。
因此，似乎正在发生的是，当单元测试运行程序执行时，运行程序的公司被用于#1(内置的VS运行程序将使用"Microsoft"，Resharper运行程序将用"JetBrains"等)，exe名称仍然以测试的Namespace开头，然后版本号也来自测试运行程序(我认为)。
这意味着，当运行单元测试时，它将始终查找并保存到与主可执行文件不同的设置文件中-因此，当您从任何程序集中访问Properties.settings.Default参数时，它在运行单元测试和运行主可执行文件时，将在不同的位置查找文件(并将其保存到不同的位置)。
通过向主exe项目中的AssemblyInfo.cs[assembly: InternalsVisibleTo("UnitTestProject1")]添加以下内容，您可以始终公开标记为内部的对象。然后，您应该可以访问测试项目中的内部对象。
https://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.internalsvisibletoattribute(v=vs.110).aspx