Can we make domain=None work without copying files?

[CharliePoole]

@jtattermusch commented on Mon Apr 11 2016

When using https://www.nuget.org/packages/NUnit.ConsoleRunner/, nunit3-console.exe fails becase it is not able to locate nunit.framework.dll. That file is usually sitting in the same directory as the assembly containing tests, but nunit3-console doesn't make an attempt to load it. Alternatively, nunit.framework.dll could be part of NUnit.ConsoleRunner package directly.

---

@CharliePoole commented on Mon Apr 11 2016

This is not something anyone else has observed, so it's probably due to some unique situation in your environment. Can you provide details of how to reproduce it? You should include info about the command-line you are using the versions of both the runner and the framework. Is the framework also installed using NuGet? What error message do you get?

FYI, the framework is entirely separate from the console runner and will eventually be separated into it's own project. The runner and engine do not reference the framework at all and can, in fact run tests written with any framework for which a driver is written. That's how we are able to run NUnit V2 tests, which is an entirely different framework, albeit with the same file name. So making the framework part of the NuGet package would be a step backward to the approach we used in NUnit V2.

---

@jtattermusch commented on Mon Apr 11 2016

It seems that what's causing trouble is the --domain=None argument. When specified, it is impossible to use nunit3-console.exe without manually copying files around.

To reproduce:

1.) Install NUnit.ConsoleRunners (version 3.2.0) nuget package to your solution and NUnit nuget package to your test project
2.) Build your test project
3.) From commandline, try to run the tests using NUnit.ConsoleRunners

packages/NUnit.ConsoleRunner.3.2.0/tools/nunit3-console.exe --labels=All --noresult --workers=1 --domain=None TestProject/bin/Debug/TestProject.dll

That results in:
Could not load file or assembly 'nunit.framework' or one of its dependencies. The system cannot find the file specified.

---

@CharliePoole commented on Mon Apr 11 2016

That's how domain=none has always worked, although it could be we neglected to bring over any documentation about it when we went to the new 3.0 documentation wiki.

NUnit creates a domain with the appbase set to the location of an assembly it is running, which is what enables it to find things. In certain extremely rare cases, people are testing features that can only run in a primary domain, so they use domain=None, copying all needed files, including NUnit components into a common directory.

Do you have a good reason to be using domain=None?

You should be aware that the default settings for ProcessModel and DomainUsage are designed to give the least trouble. That wasn't true before 3.0.

---

@jtattermusch commented on Mon Apr 11 2016

Your explanation makes sense. I was probably confused by the fact that there's no documentation about the limitations of domain=None.

I don't strictly need to use domain=None, but I am testing a projects that loads a native library under the hoods, so if there's a bug in the native library, the entire process might crash, so I am trying to go as ligthweight as possible in terms of the test harness to prevent unexpected behavior. Ideally, I'd like to use both --inprocess and domain=None (that's why I originally started to experiment with NUnitLite)

---

@CharliePoole commented on Mon Apr 11 2016

In some ways, a separate process might give you better isolation. That would be especially true if you end up using the Gui - once it is released. Then crashing the separate process wouldn't bring down the gui itself.

However, NUnitLite does give the lightest weight approach. Since the framework and NUnitLite itself are referenced from your tests, everything is in the same directory too.

---

@CharliePoole commented on Mon Apr 11 2016

Added a documentation issue and made this one an idea so we can investigate improving how domain=None actually works. Retitled the issue to match.

[CharliePoole]

Moved this to the wrong project!