Refactoring the roslyn dependency into another package

[ig-sinicyn]

The BDN 0.9.8 includes a dependency on roslyn compiler package. This results in 42 additional nuget packages, 300+ mb of binaries in the packages folder and 17 (or so) additional assembly references.

As for me it's too big overhead for the single library:)
And our perf tests project uses custom toolchain and therefore do not depend on roslyn at all.

Can the dependency be refactored into separate opt-in package?

[adamsitnik]

All options are posted here: #149 (comment)

What it gives us is managed, type safe api that allows us to compile C# apps not only on Windows but also also Unix and MacOC with Mono. So great gain, but not for free.

We could make it a package, but then it would complicate the usage for the end-users.

As for now I can's see a good solution. But I understand your point @ig-sinicyn

[AndreyAkinshin]

@adamsitnik, we can do the following:

• Add a package BenchmarkDotNet.Core which will include all infrastructure stuff.
• Add a package BenchmarkDotNet.Toolchains.Roslyn which will include all Roslyn stuff + dependencies.
• Add reference from BenchmarkDotNet to these two packages.

So, @ig-sinicyn will be able to use BenchmarkDotNet.Core with own custom toolchain, other end-users will be able to use BenchmarkDotNet (with two new dependencies) without any additional troubles.

[adamsitnik]

Ok, done. The disadvantage is that BenchmarkRunner and Switcher had to stay as part of BechmarkDotNet (not .Core) due to dependency to RoslynToolchain (unknown in BenchmarkDotNet.Core). Maybe there is some better solution, but I could not find it for this moment ;.

[ig-sinicyn]

@adamsitnik, as proposal:

What if the core logic of the BenchmarkRunner will be placed in .Core project in separate class and the BenchmarkRunner will just call its methods passing default toolchain as a call arg?

I've did something like this as we have nUnit/xUnit/MsTest support, console runner and also self-testing runner.

[adamsitnik]

@ig-sinicyn Good idea! I have implemented it right away, now you have BenchmarkRunnerCore that has single method exposed to BenchmarkRunner which can be also reused by you.

The definition:
internal static Summary Run(Benchmark[] benchmarks, IConfig config, Func<IJob, IToolchain> toolchainProvider)

Sample usage can be following:
BenchmarkRunnerCore.Run(benchmarks, config, job => job.Toolchain);