Trouble with NUnit when determining the assembly's directory

Question

I've just started to work with NUnit in order to provide some test coverage for my projects.

Within my main library.dll I need to load up configuration data from an external file that goes with the library, library.xml.

This works fine when I'm using the library, because I use the following to get the directory in which to look for the config file:

string settingspath = Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location);

The problem I've noticed is that when I'm unit testing with NUnit, it copies my assemblies to a Shadow Copy, but doesn't take any of the other files with it, so of course my init fails due to missing config files.

Should I be doing something different to locate config files from within my library? (it's a server app, and I don't want to use the standard app settings, or user's local settings, etc)

Answer 1

As you noted, Assembly.Location returns a useless temporary path somewhere in NUnit's ShadowCopyCache, and this is necessary to avoid locking the file and preventing recompilation.

I had additional problems: first, the NUnit 2 GUI runner doesn't work the same as the NUnit 3 GUI runner (now named TestCentric). Second, I sometimes need to call test methods from another executable. For reference, here are the paths I get:

NUnit 2:

AppDomain.CurrentDomain.BaseDirectory = @"C:\PathToNUnitProject\"
NUnit.Framework.TestContext.CurrentContext.WorkDirectory = @"C:\PathToNUnitProject"
NUnit.Framework.TestContext.CurrentContext.TestDirectory = @"C:\PathToNUnitProject\bin\Debug"

NUnit 3:

AppDomain.CurrentDomain.BaseDirectory = @"C:\PathToNUnitProject\bin\Debug\"
NUnit.Framework.TestContext.CurrentContext.WorkDirectory = @"C:\TestCentric\testcentric-gui-1.2.0"
NUnit.Framework.TestContext.CurrentContext.TestDirectory = @"C:\PathToNUnitProject\bin\Debug"

When the test method is called from outside of NUnit:

AppDomain.CurrentDomain.BaseDirectory = something else entirely
NUnit.Framework.TestContext.CurrentContext.WorkDirectory = Exception
NUnit.Framework.TestContext.CurrentContext.TestDirectory = Exception

For me the solution is: use NUnit.Framework.TestContext.CurrentContext.TestDirectory, as in Jeff's answer, within a try-catch. If it doesn't throw, the returned path will be the same over both NUnit versions.

Answer 2

Encountered the same problem ... following is my workout:

Before the SUT run, update AppDomain's Base Directory in this way....

String root_path = "{{your path}}";
AppDomain.CurrentDomain.SetData("APPBASE", root_path);

Answer 3

Use can use TestContext.CurrentContext.TestDirectory as mentioned by Charlie Poole from NUnit here:

The need to access files in the same directory as the test assembly is the most commonly cited reason for disabling shadow copy. However, this is spurious.

NUnit doesn't copy any assemblies: shadow copy is a function of .NET itself. Consequently, the problem needs to be viewed as "How can I access the file where it is?" rather than "How can I get the file copied to where I think it should be?"

There are three ways to locate a file that is located in the same directory as the assembly:

1) Use Assembly.Codebase - this will give you the location as a URI, which you must then tranform to an appropriate path.

2) Use the current directory, which NUnit has historically set to directory containing the executing test assembly. However, this may not be true for future releases.

3) Use NUnit's TestContext.CurrentContext.TestDirectory, which is the available in the most recent releases.

All of these approaches actually use Assembly.Codebase under the covers, with NUnit doing the work of tranforming the URI correctly in #2 and #3. The common approach of using Assembly.Location is incorrect, unless you actually want the location of the shadow copy cache.

Answer 4

We include the test resource in the test project (in this case in a 'TestData' folder).

In Visual Studio for the resource to access in the test mark

When project builds leaves the image on the 'bin\Debug' folder

and you write the path

string fullImagePath = @".\TestData\vcredist.bmp";

Answer 5

Even if shadow copying is active, AppDomain.CurrentDomain.BaseDirectory points to the original location of the test DLLs.

However, if you can embed your test data as resources in your DLL it's much safer, since there's no extra files that can get lost.

Answer 6

When unit testing it is generally recommended to avoid external dependencies such as the file system and databases, by mocking/stubbing out the routines that call them - that way your tests are more localised, less fragile and faster. See if you can remove the dependencies by providing fake configuration information.

Answer 7

you can disable shadow copying on the commandline using the /noshadow switch. Command line options are documented here

Is the external file set to be part of the build of your dll? If you include it in the project and set it to copy always in the Copy To Output in the properties of the file then it should go to the shadow directory I think.

This may help you.

Answer 8

For using reference files in my Unit Tests, I use Assembly.Codebase which works even if Shadow Copying is turned on. You might want to give it a try..

It returns a string in the Uri format.. so you'd need to create a Uri instance from the codebase string and use Uri.LocalPath to get the actual folder path.

However for production code, the BaseFolder should be retrieved from a well known place (e.g. a Registry key set via the installer on Windows). All file lookups should be rooted from this baseFolder.