Benchmarkdotnet: Update to Roslyn 2.0 when RTM is shipped to nuget.org

[adamsitnik]

3 days ago Roslyn team has published a 2.0 RC on nuget.org.

As soon as they release it as RTM we should update our dependency and release new version of BenchmarkDotNet. I have no idea when they are going to do so.

Edit:
2.0 rtm will be released when visual studio 2017 rtm is released

[adamsitnik]

Also if we 100% switch to Roslyn we should print it's version in summary (it's important because Roslyn can do some optimizations)

[adamsitnik]

update: Roslyn 2.0 will drop .NET 4.5 support, I am not sure if we will update

[alexwiese]

I'm curious as to why net45 support would be important. I'd assume that the projects using BenchmarkDotNet could easily be retargetted to net452+, it's not typically a package that gets deployed to production servers and clients, that can't easily have newer frameworks installed. Plus support has ended for net45 and net451.

[jskeet]

I'd assume that the projects using BenchmarkDotNet could easily be retargetted to net452+

That's a dangerous assumption, IMO. Noda Time targets net45 for example, and while sure, I could retarget it to net452, I wouldn't want to do so just for the sake of benchmarks. Why should my benchmarking choice dictate what platform my users can use?

It may be reasonable for projects which are effectively end-user applications, but libraries are more likely to want to keep a broad target.

If your argument is that just the benchmarking project (within a library's solution) could be updated to net452, that makes more sense. I'm just cautioning against saying "Everyone can clearly update from net45."

[alexwiese]

Yes, I imagined benchmarks being in a separate project (that could target net452) and reference a net45 library. This type of package is unique in that way.

I'm definitely not advocating forcing public libraries to retarget to net452. I would hope public libraries don't reference BenchmarkDotNet besides extensions I gusss. So _there's_ a dependency chain I haven't thought about.

[adamsitnik]

@AndreyAkinshin what about Mono?

[AndreyAkinshin]

@adamsitnik, don't worry about mono here. =)