You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 27, 2017. It is now read-only.
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.
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.
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
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.
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)
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.
@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.
The text was updated successfully, but these errors were encountered: