--domain=None does not work

[rprouse]

Tested in 3.4.1, should retest in master.

Run tests with the command line,

--domain=None or --inprocess --domain=None fails with Could not load file or assembly 'nunit.framework' or one of its dependencies. The system cannot find the file specified. I am running using the installed console from the test project bin directory.

Ideally, the console is in a different directory and doesn't have a copy of the framework sitting in the build directory. Our build output isn't the best test for this. I tested with an installed version of the console.

[CharliePoole]

Domain=None has only ever worked if the test assembly and all nunit assemblies are in the same directory. I talked about removing it but there are a few odd uses for testing code that can only ever run in a primary AppDomain.

[jcansdale]

I use it: 😉
https://github.com/nunit/nunit3-tdnet-adapter/blob/master/src/NUnitTDNet.Adapter/EngineTestRunner.cs#L51

The NUnit assemblies will loaded into the LoadFrom context (rather than being in the same directory).

[CharliePoole]

@jcansdale Unless one of our contributors slipped something past us :-) NUnit doesn't use LoadFrom except in the presence of a special package setting that is not accessible to users. Is that what you are using? If you are, it's a little risky, since it's not a published interface. We can look into this more closely if you like.

@rprouse Is domain=None failing in cases where you have used it successfully before?

[jcansdale]

It's only when I create a TestPackage object directly that I use the AddSetting("DomainUsage", "None") setting. It's my code that resolves the NUnit assemblies and loads them using LoadFrom. I don't actually use this setting with the NUnit console (which I realize this issue is about). Sorry. 😄

[CharliePoole]

So, what I imagine happens is that NUnit attempts to load the assemblies and finds the copy you already loaded - I'm slightly surprised at that, since they are in the LoadFrom context.

There is actually a "secret" setting that will cause NUnit to create an AssemblyResolver that will do a LoadFrom - search for ImageRequiresDefaultAppDomainResolver.

[CharliePoole]

@rprouse I agree there's nothing critical about this one. I was surprised you could run domain=none, but I realized it will work if you are in the nunit project and running in the bin directory. We should really address what this setting does and what we want it to do. The defects can either be fixed or documented as far as I'm concerned.

@jcansdale's use is actually much safer than use from the command-line. He specifies it in the package because he has already created the appdomain and doesn't want a new one.

[rprouse]

I don't think we can do much with domain=None to fix it. There are so many ways that it could go wrong with multiple assemblies referencing different versions of the same assembly, etc. We could document it, but if we do, we should probably add a warning to the command line help too.

[CharliePoole]

Issue moved to nunit/nunit-console #28 via ZenHub