Hi, I have a tests, in which Setup I write some entries in the config file, and on tear-down I remove them.

I use:

var config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);

All this works well under NUnit or Reshrper, but fails in NCrunch. I.e. looks like the writing in the config file works, but later on during the test, the runner does not find the right config file, because the tests fail with config entry not found.

Stepping trough the Setup method, I see that the above line of code uses FilePath "C:\\Users\\sunny\\AppData\\Local\\NCrunch\\2424\\19\\MobileServices.Tests\\bin\\Debug\\MobileServices.Tests.dll.config.ncrunchconfig

As the entries I create are for WCF endpoints (I need to test that my startup class succeeds to bind the proxies), looks like when the WCF infrastructure kicks in to get the config file, it gets something else.

Running the same thing under resharper shows that it gets/writes in MobileServices.Tests.dll.config, and it works.

Any idea how to approach this problem?

Hi,
I experience kind of the same issue.
In my test project (a project that contains tests) I have a standard app.config file and a custom config DataAccess.InMemory.config.
In runtime a test has no problems with accessing app.config, but when I try to open DataAccess.InMemory.config test can't find it.
It tries to look at C:\Users\XXX\AppData\Local\NCrunch\5804\117\TestResults\ff598651-3720-4dee-9943-3a69ae9dd65d\Out\DataAccess.InMemory.config - but there is no such file in the directory. It is empty.
Here is a piece of code I use to load the config file:

var configFile = "DataAccess.InMemory.config";
var fileMap = new ExeConfigurationFileMap { ExeConfigFilename = configFile };
var configuration = ConfigurationManager.OpenMappedExeConfiguration(fileMap, ConfigurationUserLevel.None);

On this stage configuration.FilePath quals to "C:\\Users\\XXX\\AppData\\Local\\NCrunch\\5804\\123\\TestResults\\04e49901-389d-4fc5-9e18-f308a12bdc6d\\Out\\DataAccess.InMemory.config"
So, it looks into "Out" directory for the file instead of project folder. Is it the way it has to work? If so, how make the config visible for test executed by ncrunch?
A note: the same test works perfectly when I run it by visual studio unit testing tools.

Hi Roman,

Thanks for posting! Can you give me any more details about the DataAccess.InMemory.config? Is this a statically created file that exists as part of your project and is copied to the output directory, or is it dynamically created at run-time through one of your tests?

If it's a static file and needs to be copied to the testing directory, how do you have this configured? Are you using [DeploymentItem] or do you have configuration in your MSTest settings that specifically targets the file?

Hi Roman,

This makes good sense now. NCrunch doesn't support MSTest's global configuration settings, so if you specify deployment items globally then they won't be copied to the output directory.

There are two ways you can work around this.

The first is to use the [DeploymentItem] attribute on all tests that require a particular resource to be copied to the MSTest 'Out' directory (may not work so well for you).

The second is to reference the config file using a relative path that reaches out of the MSTest 'Out' directory and back into your source solution. This should allow your test to work with both the Visual Studio testing tools and NCrunch.

Supporting the global MSTest configuration is something I looked into doing when implementing the MSTest support, though unfortunately it requires a large amount of integration and at the time I couldn't find a reliable way to do it. There are also changes coming in NCrunch that would be logically incompatible with this kind of configuration, so I've instead taken to trying to encourage people to avoid using it.

I definitely have to recommend referencing your configuration file as it sits in your solution by using a relative path. The location of MSTest's 'Out' directory is always consistent relative to your source code, so I think that this could be an ideal solution for you. Otherwise it may be worth having a look at other test frameworks that do not use MSTest's file copying approach (such as NUnit).