.net - .NET 的内部工作原理——内置设置加载器可以通过代码访问吗？

Question

我加入了一个项目，其中 .NET Windows Forms 应用程序正在使用 Settings mechanism (项目> 属性> 设置)以保留用户设置和应用程序设置。我创建了使用 LoadAssembly(<main application EXE file>) 的命令行工具执行主应用程序的一些功能。在调用主应用程序的方法时，一切正常除了涉及到设置——当然，因为它们没有加载——设置加载器被跳过。

但该应用程序严重依赖于设置，因此我需要显式调用该设置加载器。但我找不到它:我已经分析了添加了设置的空白.NET项目的所有文件，但找不到加载例程。

我认为在最坏的情况下我可以解决问题并实现

• 定位设置文件
• 显式加载其内容

但我不喜欢重新发明轮子，尤其是我不喜欢在 .NET 平台上加载设置的非透明处理。
有什么方法可以调用.NET 框架使用的内置代码来加载My.Settings在应用程序启动时？

注意:应用程序是用 VB.NET 编写的，但我认为对于 C# 也是一样的，所以如果你愿意，请毫不犹豫地展示 C# 的思维方式。

Answer 1

我最近发现，处理设置的默认方式不允许甚至不支持我的方案。评估

ConfigurationManager.OpenExeConfiguration( ConfigurationUserLevel.PerUserRoamingAndLocal).FilePath

在从原始应用程序调用和从加载的程序集调用时提供不同的本地设置目录。比较相同方法的输出:

直接调用时:

C:\Users\Miroxlav\AppData\Local\WindowsApplication1\WindowsApplicationSetting_Url_za1afclumj0mqqjsghdpysdumjr5jd21\1.0.0.0\user.config

当作为从另一个应用程序调用的已加载程序集的一部分调用时:

C:\Users\Miroxlav\AppData\Local\WindowsApplication1\TestWindowsApplicationSet_Url_cxikfslvgbja50yw4lvnvugko41ou5jz\1.0.0.0\user.config

因此对于默认设置提供程序，甚至无法直接确定配置文件的位置。 这基本上使直接检索加载程序集的 My.Settings 的所有潜在后续步骤无效(没有帮助文件，使用固定设置的其他解决方法等 - 同时保持默认设置提供程序)

出路可以写custom settings provider它将设置存储在普遍可访问的位置，尽管它的开销比我预期的要大得多。

更新:作为一种快速解决方法，我实现了辅助文件以在主应用程序启动时保存配置位置。当主应用程序的代码作为加载的程序集启动时，我是 restoring My.Settings from the config file在帮助文件中保存的位置找到。