Use a programmed search to locate extensions in place of default addins files.

[CharliePoole]

Each of our console packages is distributed with an addins file in the engine directory. The file is used to find extensions that use our default naming pattern in one or more default locations. The content is slightly different for each package type, i.e. nuget vs chocolatey, but the structure of the paths contained is quite similar.

This issue proposes to replace the user of default addins files with an algorithmic approach. That is, code in ExtensionManager would incorporate the logic needed to look for extensions in the same places as our default files, which would no longer be distributed. We would, however, continue to use any addins files found, since users may continue to create them.

Addins file are very useful for adding extensions on an adhoc basis, so we will continue to use them. However, an algorithmic approach has a two main advantages...

• Users will no longer be tempted to erroneously change our distributed addins files.
• This approach is more extensible. For example, it will allow us to walk through all parent directories searching for extensions at a higher level. This is essential to use of extensions in standalone executables and is the primary reason for making the change at this time (see Simplify locating of addins #488).

@OsirisTerje @nunit Comments please?

[OsirisTerje]

This is more like the way Is see other systems do the same thing, so I am in favor of this approach. I believe it will make it easier, also what is said in #488 makes sense to me.

It could also open up an approach for adding extensions to other parts of the nunit sphere.

[CharliePoole]

I hacked together a local experiment and extensions will work with dotnet nunit using this approach, so that's big.

To use extensions elsewhere, you would probably want to complete the job of separating it out as was planned for V4. It's not breaking in any way so could even be V3. I've done that for TestCentric where there's a separate Extensibility package. One good use for NUnit would be to allow NUnitLite or it's successor to host extensions.