Support building only part of the target frameworks

[thomaslevesque]

With the multiplication of target frameworks for the library and tests, the build times have been getting longer and longer. Although all these TFMs are there for a good reason, it can significantly slow down the feedback loop when working on the project.

As discussed in chat with @blairconrad, we should consider a way to build only some TFMs.

A possible way to do this would be to define "target framework sets" that define the target frameworks for each project. The default set would be the "full" set, including all currently supported target frameworks. We could then introduce other sets with only some of the target frameworks for faster development cycle.

[thomaslevesque]

Issues so far:

• The analyzer tests depend on the unit tests project, so if the unit tests are built only for e.g. netcoreapp3.0, the analyzer tests need to also support that target (there's a bit of work to do to make the Roslyn compilation work). OR we can extract a "test utilities" project that targets the lowest possible TFM, and this way we can avoid changing the analyzer tests. But I think these tests should run on netcoreapp anyway, if only to support non-Windows build.

• The approval tests will fail if a target is missing. Maybe we could just skip the test if the assembly can't be found.

That's all for now. Some stats (for things that are already working):

Build target \ Target set	Full target set	Minimal target set
build	26s	12s
spec -s	25s	5s
integ -s	31s	7s

(measured twice for each scenario, took the second result, which is usually shorted because there's less work to do, and rounded up)

So I think it's worth it!

[blairconrad]

OR we can extract a "test utilities" project that targets the lowest possible TFM, and this way we can avoid changing the analyzer tests.

I've no problem with this.

But I think these tests should run on netcoreapp anyway, if only to support non-Windows build.

Also a good idea!

The approval tests will fail if a target is missing. Maybe we could just skip the test if the assembly can't be found.

I think that's fine. If the assembly is missing for an unexpected reason, we'll probably notice! On the other hand, if I'm running the tests and interested in them running fast, I'm probably doing something like build spec integ unit anyhow, so this change could be deferred, if you haven't the appetite for it now. Your choice.

[thomaslevesque]

if you haven't the appetite for it

Oh, it's not like it's a big change ;)

[thomaslevesque]

This change has been released as part of FakeItEasy 5.4.0.