Separate APIs for extension developers

[CharliePoole]

Part of #1607

in #770, @ChrisMaddock proposed the following...

Engine API assembly

Funny one - I currently see the API assembly as serving two distinct purposes.

1. The API for runners wishing to reference the engine
2. The assembly to be referenced by engine extensions

Based on the fact that driver extensions currently need to be loaded by agents, there is a potential need for extensions to be able to target legacy platforms, and thus the API assembly as well. This is a restriction that's only necessary for "purpose 2" however - so I wonder if there's value in splitting the API assembly? This would give us e.g.:

1. nunit.engine.api.dll: Contains all the code in the current API assembly, targets the same platform(s) as nunit.engine.dll
2. nunit.extensions.api.dll: A new, super-slim assembly, which contains only the interfaces required by extension developers (IProjectLoader, IResultWriter etc.). This assembly could continue to target the lowest platform we see fit - potentially .NET 2.0.

There are two separate sorts of APIs used to develop extensions:

1. The basic Types that form part of NUnit's extensibility model, without regard to just what is being extended. These include ExtensionAttribute, TypeExtensionAttribute, ExtensionPointAttribute, ExtensionPropertyAttribute, IExtensionNode and IExtensionPoint.

2. Interfaces that must be implemented for specific extension points. These currently include IDriverFactory, IFrameworkDriver, IProject, IProjectLoader, IResultWriter, ITestEventListener and IService. Implementors of an extension make use of the interfaces used for the extension point they are targeting. For example, an event listener only needs to implement ITestEventListener.

The first set of APIs has already been removed from nunit.engine.api and are to be found in nunit.extensibility.api. (See note below) That assembly, however, has not yet been published in a separate package.

The second set of APIs could be published in a new nunit.engine.extensibility.api assembly or in multiple assemblies similar to nunit.engine.extensibility.listeners in naming. The first decision is whether to have one just such assembly or one per extension point. Exact naming can be decided later.

Note: The absence of "engine" in the current nunit.extensibility.api assembly is by design. Right now, we only have engine extensions, but the mechanism may be used for other components as well.

Tasks

• Decide whether to have one api per extension point or to combine them.
• Publish package with nunit.extensibility.api assembly.
• Publish package or packages for the interfaces used by our extension points.

@nunit/engine-team All comments are welcome. I'd particularly appreciate your thoughts on how many different api assemblies are needed. A single assembly means that breaking changes are more likely but multiple assemblies could mean more work. A single assembly might also mean that we need to commit to avoiding breaking changes for these interfaces.