Replacement for RuntimeFrameworkService

[ChrisMaddock]

RuntimeFrameworkService suffers from a number of problems:

1. Lack of thread-safety (Refactor RuntimeFramework to ensure thread-safety #173) - preventing improvements in other areas (Load packages in parallel #140)
2. Mix of functionality relating to runtimes and target frameworks, leading to confusion in code (e.g. use of Runtime.Any, Split RuntimeFramework into separate RuntimeFramework and TargetFramework classes #406).
3. High-overhead in certain usecases - e.g. every test run currently calculates and discovers all available runtimes, when only a minority of runners require that information.
4. Limited testing, due to tight integration of assembly inspection/File system requirements, and logic.
5. Lot's of netfx specific functionality, which can't be compiled for the .NET Standard builds
6. Reliance on two different versions of Mono Cecil, due to no version of Cecil having support for both .NET 2.0 and .NET Standard.

After spending a couple of years teasing round the edges of this, and not making a lot of progress (#407, #402, #408, #670, #406) I'd like to instead propose a wholesale replacement for these classes. I'm marking this as high priority, as it's an area which is going to need lots of upcoming development for the .NET Standard improvements - and I'd like to create a better structure here, before we start building on top of it.

---

I'm proposing two new services to replace it:

1. AssemblyTargetingService: Responsible for everything around what an assembly was built to target. Would be used to inspect and annotate test packages, and inspect engine extensions.
2. RuntimesService: Responsible for all functionality around discovering available runtimes, and deciding on the runtime to be used for each agent.

I'd then like the Obsolete the current RuntimeFrameworkService, and remove in v4.

Thoughts welcome. 🙂

[CharliePoole]

@ChrisMaddock Regarding removal of RuntimeFrameworkService... it might be possible before v4, because it's not exposed outside the engine. The IRuntimeFrameworkService interface is not exposed but IAvailableRuntimes is. The latter must be implemented somewhere, but does not have to be in the same class.

FYI, I'm doing similar work in the GUI, but incrementally. I'm thinking about how to make you and the @nunit/engine-team members aware of each new thing I do... more on that to come.

[CharliePoole]

@ChrisMaddock Have you done anything on an AssemblyTargetingService ? I'm finding I need one in the work I'm doing for eliminating Mono.Cecil from the core. If you have, I'll take a look, otherwise, I'll start from scratch.

[ChrisMaddock]

Hi @CharliePoole, I think I made a start - but it wasn't very substantial, and was on a machine I can't get to for a couple of days. I think you may be better starting from scratch here, sorry.