## Configuration Files

NUnit uses configuration files for the test runner executable – either nunit-console.exe or nunitgui.exe – as well as for the tests being run. Only settings that pertain to NUnit itself should be in the nunit-console.exe.config and nunit-gui.exe.config, while those that pertain to your own application and tests should be in a separate configuration file.

### NUnit Configuration Files

One main purpose of the nunit-console and nunit-gui config files is to allow NUnit to run with various versions of the .NET framework. NUnit is built using versions 1.1 and 2.0 of the framework. The two builds are provided as separate downloads and either build can be made to run against other versions of the CLR.

As delivered, the <startup> section of each config file is commented out, causing NUnit to run with the version of .NET used to build it. If you uncomment the <startup> section, the entries there control the order in which alternate framework versions are selected.

### Test Configuration File

When a configuration file is used to provide settings or to control the environment in which a test is run, specific naming conventions must be followed.

If a single assembly is being loaded, then the configuration file is given the name of the assembly file with the config extension. For example, the configuration file used to run nunit.tests.dll must be named nunit.tests.dll.config and located in the same directory as the dll.

If an NUnit project is being loaded into a single AppDomain, the configuration file uses the name of the project file with the extension changed to config. For example, the project AllTests.nunit would require a configuration file named AllTests.config, located in the same directory as AllTests.nunit. The same rule is followed when loading Visual Studio projects or solutions.

> Note: The above only applies if a single AppDomain is being used. If an NUnit project is loaded using a separate AppDomain for each assembly, then the individual configuration files for each of the assemblies are used.

Generally, you should be able to simply copy your application config file and rename it as described above.

It is also possible to effect the behavior of NUnit by adding special sections to the test config file. A config file using these sections might look like this:

    <?xml version="1.0" encoding="utf-8" ?>
    <configuration>
      <configSections>
        <sectionGroup name="NUnit">
          <section name="TestCaseBuilder"
    	    type="System.Configuration.NameValueSectionHandler"/>
          <section name="TestRunner"
    	    type="System.Configuration.NameValueSectionHandler"/>
        </sectionGroup>
      </configSections>

      <NUnit>
        <TestCaseBuilder>
          <add key="OldStyleTestCases" value="false" />
        </TestCaseBuilder>
        <TestRunner>
          <add key="ApartmentState" value="MTA" />
          <add key="ThreadPriority" value="Normal" />
    	  <add key="DefaultLogThreshold" value="Error" />
    	</TestRunner>
      </NUnit>

      ...

    </configuration>

The entries in the above file are all set to default values. The meaning of each setting is as follows:

#### OldStyleTestCases

If set to "true" NUnit will recognize methods beginning "test..." as tests. The prefix is case insensitive.

#### ApartmentState

Sets the apartment state for the thread used to run tests.

#### ThreadPriority

Sets the thread priority for the test thread.

#### DefaultLogThreshold

Sets the level for logging captured by NUnit. In the current version only log4net logging is captured, so the level must be one that is defined by log4net.