Hi,
In our project we have a test that rewrites the .config file to add and remove sections depending the test executing. In our case it is necessary to do it like this.
It seems that NCrunch copies the .config file to .ncrunchconfig and when calling 'ConfigurationManager.GetSection()' the later config file is used instead of the original .config file (it is also in the directory).
Is this correct?
The test works when running with either MsTest or Resharper.
When the test rewrites the config file it finds the config file by calling 'ConfigurationManager.OpenExeConfiguration("assembly filename.dll").FilePath'.
Here it is provided with the config filepath 'assembly filename.dll.config'.
If the part about the .ncrunchconfig file is correct, shouldn't the 'OpenExeConfiguration' provide the filepath to the .ncrunchconfig file?
With Best Regards
Kristian Hald
Remco NCrunch Developer
#7277
04 May 2015 22:31 UTC
Hi Kristian,
Thanks for sharing this. Your understanding of how NCrunch uses configuration is correct - it makes a copy of the config file and manipulates it so as to introduce binding redirections allowing it to exert tighter control over the test environment. This means that the application domain responsible for running your test will be backed onto the .ncrunchconfig file. This is handed into the constructor for the test app domain.
I'm not very well familiar with the behaviour of the OpenExeConfiguration method, but if this method allows you to pass a .EXE from which to infer a config file, then I would expect that the method could only ever return the default config file as would be loaded if the EXE were invoked directly. The only way such a method could know the name of a config file specified in an appdomain constructor would be through analysing code (which is problematic and I bet MS wouldn't do it).
Therefore I think the only way to solve this for you is to redesign the code involved. You can use a compiler conditional around the call to OpenExeConfiguration (i.e. #if NCRUNCH) to introduce alternative behaviour, or consider introducing an additional layer of abstraction into your test. It may be worthwhile checking yourself for the presence of a .ncrunchconfig file prior to looking for the default.
Cheers,
Remco
Thanks for sharing this. Your understanding of how NCrunch uses configuration is correct - it makes a copy of the config file and manipulates it so as to introduce binding redirections allowing it to exert tighter control over the test environment. This means that the application domain responsible for running your test will be backed onto the .ncrunchconfig file. This is handed into the constructor for the test app domain.
I'm not very well familiar with the behaviour of the OpenExeConfiguration method, but if this method allows you to pass a .EXE from which to infer a config file, then I would expect that the method could only ever return the default config file as would be loaded if the EXE were invoked directly. The only way such a method could know the name of a config file specified in an appdomain constructor would be through analysing code (which is problematic and I bet MS wouldn't do it).
Therefore I think the only way to solve this for you is to redesign the code involved. You can use a compiler conditional around the call to OpenExeConfiguration (i.e. #if NCRUNCH) to introduce alternative behaviour, or consider introducing an additional layer of abstraction into your test. It may be worthwhile checking yourself for the presence of a .ncrunchconfig file prior to looking for the default.
Cheers,
Remco
Post a reply
Log in to reply.