É realmente um bug com ConfigurationManager.Abrir a configuração da roda?

a documentação para estados:

Abre o ficheiro de configuração do cliente indicado como uma configuração objecto.

também diz que exePath é " o caminho do ficheiro executável (exe)"

o método é suposto abrir o ficheiro *.exe.config para o executável na localização indicada por exePath, e que um ConfigurationErrorsException será lançado se "um ficheiro de configuração não puder ser carregado.".

o seguinte código utiliza o caminho de um o não-executável e a pasta dessa localização não contém *.exe.ficheiros de configuração. No entanto, o código executa sem quaisquer exceções, nem qualquer outro sinal de um argumento inválido.

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);

No entanto, agora lentamente vai ficar desactualizado para a nova configuração baseada em JSON Core. NET, e não vai ser revisto ou corrigido de qualquer maneira.

Então, isto é devido a um erro nesta sobrecarga do método OpenExeConfiguration?

Só queria uma segunda, e a minha opinião antes de falar sobre a MS Connect. E A ligação está em baixo de momento.

ADDED: If I call OpenExeConfiguration with a valid exePath, to a real executable (tested), with a valid .config file, then it reads but does not parse the file. Tenho de pedir o xml para a secção appSettings e analisá-lo eu mesmo, usando o resultado desta resposta para AppSettings a partir de ficheiros personalizados. Isto aumenta a minha suspeita de que este código não é comumente usado neste modo, foi aceite como trabalho e não revisto, e poderia, portanto, ser carro.

tenho a certeza que vai receber pouca atenção com a nova API de configuração do núcleo.net substituindo o antigo XML apenas um.

Author: Community, 2016-10-08
Source

2 answers

Então tem duas preocupações que eu entendo:

  1. O OpenExeConfiguration não falha para arquivos com extensões que não "exe".

  2. O OpenExeConfiguration não falha se o ficheiro de configuração ainda não existir.

Entendo ambos os pontos, mas diria que ambos são discutíveis.

  1. O ficheiro executável não significa necessariamente o ficheiro com o qual .extensão exe. Sim, no Windows isso geralmente é verdade, mas vamos levar o Linux por exemplo (e podemos fazer isso porque o. NET não está restrito apenas ao Windows). Eu posso ter executável arquivo. NET com qualquer extensão (mesmo notas.txt), ou sem extensão, não importa. Posso executar esse ficheiro com "mono notes".txt " e vai correr como de costume.

  2. O ficheiro de Configuração Não existente não é uma condição excepcional para o objecto Configuration. Ele até tem uma propriedade chamada HasFile que indica se esse arquivo existe ou não. Eu posso fazer o seguinte com o seu código: 

    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
 0
Author: Evk, 2016-10-08 17:10:23

Não sei se pode ser chamado de bug ou não, mas

De acordo com Esta Referência

De acordo com http://social.msdn.microsoft.com/Forums/en-US/winforms/thread/3943ec30-8be5-4f12-9667-3b812f711fc9 o parâmetro é a localização de um exe, e o método então procura a configuração correspondente a esse exe (acho que o nome do parâmetro de exePath faz sentido agora!).

Também dá uma solução ... 

ExeConfigurationFileMap map = new ExeConfigurationFileMap { ExeConfigFilename = "EXECONFIG_PATH" };
Configuration config = ConfigurationManager.OpenMappedExeConfiguration(map, ConfigurationUserLevel.None);
 0
Author: Miguel Sanchez, 2017-05-23 10:32:29