Rebuild .Net Framework projects

[timcassell]

Resolves #1773

[timcassell]

Looks like CI is unhappy trying to build the classic .Net Framework test project. Can you help me fix it @AndreyAkinshin?

[AndreyAkinshin]

Here is the problem:

D:\a\BenchmarkDotNet\BenchmarkDotNet\tests\ClassicNetFrameworkTests\BenchmarkDotNet.IntegrationTests.ClassicNetFramework.csproj(153,5): error : This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them.  For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is ..\..\packages\xunit.core.2.5.0\build\xunit.core.props.

We use .NET SDK for all the build-related operations that don't support classic .NET applications. If we want to fix it, we should do the following:

• Use full VS MSBuild on Windows (that adds an additional requirement for the development setup)
• Exclude this project on Linux/macOS or create a crazy build toolset that involves Mono MSBuild.

I would like to avoid this. This looks like an overcomplication of our build script with low visible benefits. Do we really need the ClassicNetFramework project?

[timcassell]

Do we really need the ClassicNetFramework project?

I just wanted to be sure that it still works properly. It worked on my Windows machine when I tested it, so I suppose I can just remove it from the sln.

[timcassell]

I moved the tests to their own sln for manual execution (and I also moved the existing manual tests to that sln).

Now, the only thing we don't support is recompiling for classic Mono with different target frameworks. I don't think it's worth adding that support, as we would need new runtime monikers (Mono461 etc) and toolchains, but what do you think @AndreyAkinshin?

[adamsitnik]

First of all, thank you for your contribution @timcassell

This PR brings a LOT of complexity, just to support one very unique scenario that gets less and less important every year (I doubt anyone will care about comparing .NET vs .NET Framework in two years from now). I don't believe it's worth it.

I recommend that we rather simply prefer CsProjClassicNetToolchain over RoslynToolchain when users are running the benchmarks that compare multiple runtimes. It should solve this problem and require less changes.

[timcassell]

I recommend that we rather simply prefer CsProjClassicNetToolchain over RoslynToolchain when users are running the benchmarks that compare multiple runtimes.

I think we could actually just always default to CsProjClassicNetToolchain, since in my testing, it always succeeded, even with the classic csproj. Users could then just manually specify RoslynToolchain if they really need it.

[adamsitnik]

@timcassell thank you for addressing my feedback, it looks much better now.

PTAL at my comments, we are almost there!

[adamsitnik]

LGTM, thank you @timcassell !