获取配置文件路径时使用 AppDomain 和 ConfigurationManager 有什么区别？
获取当前配置文件的文件路径时，使用AppDomain命名空间和ConfigurationManager命名空间有什么区别？什么时候你会使用其中一种而不是另一种？
例如，两者都返回相同的路径：
string f1 = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile;
string f2 = ConfigurationManager.OpenExeConfiguration( ConfigurationUserLevel.None ).FilePath;
When getting the file path of the current configuration file, what is the difference in using the AppDomain namespace and the ConfigurationManager namespace? And when would you use one over the other?
For example, both return the same path:
string f1 = AppDomain.CurrentDomain.SetupInformation.ConfigurationFile;
string f2 = ConfigurationManager.OpenExeConfiguration( ConfigurationUserLevel.None ).FilePath;
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
这取决于您何时以及为何需要配置文件。其要点是：
作为一个粗略的示例，我们假设有一个应用程序可以使用动态添加/删除的插件。您不希望在应用程序的生命周期中将这些插件程序集保留在内存中，这会达不到目的，因此您在应用程序中创建一个单独的 AppDomain。它将处理应用程序和插件程序集之间的加载和通信，执行您需要对它们执行的任何操作，并且应用程序可以在需要时通过删除 AppDomain 来卸载程序集。
插件 AppDomain 有相当多的设置，您希望将它们与客户端配置文件分开，因此当您创建 AppDomain 时，您可以指定单独的文件位置。在that AppDomain 中，配置文件就是那个文件。
不过，客户端配置可能取决于使用它的人（并且他们可能能够更改它并自定义其设置）。您宁愿使用由给定用户隔离的应用程序范围的配置，甚至不让他们选择扰乱特定于插件的设置（或其他用户的设置）。理论上，ConfigurationManager 可以从任意数量的文件中提取。
这是一个非常普遍的想法，它放弃了所有的实现，但希望这开始说明两者可能有何不同。
以下是 AppDomainSetup 和 OpenExeConfiguration() 也是如此，这可能很有用，并且包含指向配置相关资源的其他链接。
It comes down to when and why you want a configuration file. The gist of it is this:
As a rough example, let's take a hypothetical application that can use plugins that it adds/removes on the fly. You don't want to have to keep those plugin assemblies in memory for the life of the application, that would defeat the purpose, so you create a separate AppDomain within your application. It will handle the loading and communication between the app and the plugin assemblies, do whatever you need to do with them and the app can unload the assemblies by dropping the AppDomain whenever it needs to.
The plugin AppDomain has quite a few settings that you'd rather keep separate from the client configuration file, so when you create the AppDomain you specify the separate file location. Within that AppDomain, the configuration file is that file.
The client configuration, though, may depend on who's using it (and they may have the ability to change it and customize their settings). You'd rather use an application-wide configuration that's segregated by a given user instead and not even give them the option to mess with the plugin-specific settings (or other user's settings). The ConfigurationManager could theoretically pull from any number of files.
That's a very general idea that handwaves away all of the implementation, but hopefully that starts to illustrates how the two might differ.
Here are the MSDN pages for both the AppDomainSetup and OpenExeConfiguration() as well, which may be useful and has additional links to configuration-related resources.