Visual Studio support in this release is a sort of "poor man's integration." We have implemented a number of features while avoiding any that would require using an Addin or otherwise interacting with the Visual Studio extensibility model.
The most convenient way to do this is to set up a custom tool entry specifying the path to NUnit as the command. For a VS2003 C# project, you can use $(TargetPath) for the arguments and $(TargetDir) for the initial directory.
With Visual Studio VS2005 this becomes a bit harder, because that release changed the meaning of the 'Target' macros so they now point to the intermediate 'obj' directories rather than the final output in one of the 'bin' directories. Here are some alternatives that work in both versions:
If you would like to debug your tests, use the Visual Studio Debug | Processes... menu item to attach to NUnit after starting it and set breakpoints in your test code as desired before running the tests.
When the nunit-console program is run in debug mode under Visual Studio, it detects that it is running in this mode and sends output to the Visual Studio output window. Output is formatted so that double clicking any error or failure entries opens the appropriate test file at the location where the failure was detected.
When Visual Studio support is enabled, the File Open dialog displays the following supported Visual Studio project types: C#, VB.Net, J# and C++. The project file is read and the configurations and output assembly locations are identified. Since the project files do not contain information about the most recently opened configuration, the output assembly for the first configuration found (usually Debug) is loaded in the GUI. The tree shows the project as the toplevel node with the assembly shown as its descendant.
Beginning with NUnit 2.2.2, you may also open a Visual Studio project by dragging it to the gui tree control.
When tests are run for a Visual studio project, they run just as if the output assembly had been loaded with one exception. The default location for the config file is the directory containing the project file and it's default name is the same as the project file with an extension of .config. For example, the following command would load the tests in the nunit.tests assembly using the configuration file nunit.tests.dll.config located in the same directory as the dll.
nunit.exe nunit.tests.dllOn the other hand, the following command would load the tests using the configuration file nunit.tests.config located in the same directory as the csproj file.
nunit.exe nunit.tests.csprojThe same consideration applies to running tests using the console runner.
When Visual Studio support is enabled, solution files may be opened as well. All the output assemblies from contained projects of the types supported will be loaded in the tree. In the case where all contained projects are located in the subdirectories beneath the solution, it will be possible to load and run tests using this method directly.
Beginning with NUnit 2.2.2, you may also open a Visual Studio solution by dragging it to the gui tree control.
When a solution contains projects located elsewhere in the file system, it may not be possible to run the tests - although the solution will generally load without problem. In this case, the Project Editor should be use to modify and save the NUnit test project so that there is all referenced assemblies are located in or beneath the application base directory.
When Visual Studio support is enabled, the Project menu contains an active entry to add a VS project to the loaded project. The output assembly will be added for each of the configurations specified in the VS project.