ConfigurationManager.OpenExeConfiguration(string exePath)的文档状态:
作为configuration打开指定的客户端配置文件对象。
它还声明exePath是"可执行文件(exe)的路径"
该方法应该在exePath指定的路径上为可执行文件打开*.exe.config文件，并且如果"配置文件无法加载"将抛出ConfigurationErrorsException。
下面的代码使用了一个非可执行文件的路径，并且该路径的目录不包含*.exe。配置文件。然而，代码执行时没有任何异常，也没有任何其他无效参数的迹象。
var configs = Directory.GetFiles("C:\NoConfig", "*.config");
Debug.Assert(configs.Length == 0);
File.WriteAllText("C:\NoConfig\notes.txt", "This is not an executable, and there is no .config file in its folder.");
var config = ConfigurationManager.OpenExeConfiguration("c:\notes.txt");
Debug.Assert(config != null);
然而，它现在将逐渐被新的基于。net Core JSON的配置弃用，并且无论如何都不会被审查或修复。
那么，这是由于OpenExeConfiguration方法的重载中的错误吗?
我只是想要第二个，在我在MS Connect上提出它之前，n是我的意见。连接暂时关闭。
add:如果我用有效的exePath调用OpenExeConfiguration，到一个真正的可执行文件(测试)，使用有效的.config文件，那么它读取但不解析文件。我必须请求appSettings部分的xml并自己解析它，使用从自定义文件到AppSettings的答案的解决方案。这增加了我的怀疑，这段代码在这种模式下并不常用，已经被接受为工作而没有被审查，因此可能有bug。
我敢肯定它会受到很少的关注，因为新的。net Core配置API取代了旧的XML。
所以我理解你有两个问题:
-
openexecconfiguration对于扩展名不是"exe"的文件不会失败。
-
openexecconfiguration不失败，如果配置文件不存在
我理解这两点，但我得说这两点都是有争议的。
-
可执行文件不一定是指扩展名为。exe的文件。是的，在Windows上这通常是正确的，但是让我们以Linux为例(我们可以这样做，因为。net不仅限于Windows)。我可以有任何扩展名的可执行。net文件(甚至notes.txt)，或者根本没有扩展名，这都没关系。我可以很高兴地用"mono notes.txt"执行该文件，它将像往常一样运行。
-
不存在的配置文件不是
Configuration对象的例外条件。它甚至有一个名为HasFile的属性，用于指示该文件是否存在。我可以用你的代码做以下事情:var config = ConfigurationManager.OpenExeConfiguration("c:\notes.txt"); // config.HasFile == false here config.AppSettings.Settings.Add("test", "test"); config.Save(ConfigurationSaveMode.Full, true); // config.HasFile == true here, and file is written to disk
不确定是否可以称之为bug，但是
根据这个参考
根据http://social.msdn.microsoft.com/Forums/en-US/winforms/thread/3943ec30-8be5-4f12-9667-3b812f711fc9参数是exe的位置，然后该方法查找配置对应的exe(我猜的参数名称exePath现在有意义了!)。
它也给出了一个解决方法——
ExeConfigurationFileMap map = new ExeConfigurationFileMap { ExeConfigFilename = "EXECONFIG_PATH" };
Configuration config = ConfigurationManager.OpenMappedExeConfiguration(map, ConfigurationUserLevel.None);