Support 32bit benchmarks for .NET Core

[adamsitnik]

I did some tests today.

It's possible to get x86 working, but only for Windows.
Issue in CoreCLR for porting x86 to Linux.

Getting it working on Windows today: I have noticed that dotnet cli which we rely on has huge limitation (dnx did not have it!): every project.json based project targets x64 by default. We can not tatget x64 from x86 programs, so as long as we don't set up "platform": "x86", in the project that contains benchmarks it's impossible to get it working (bad image exception) ;) We can do this for auto-generated project.json, but not for the one that contains benchmarks.

I will wait with further work until Roslyn 2.0 goes RTM. Then I plan to move from dotnet cli as our build engine to Roslyn. We should be able to get it working then.

[adamsitnik]

@AndreyAkinshin tried that today with the new "msbuild" based dotnet cli. IMHO It's still too many workarounds to give it a go

<PlatformTarget>x86</PlatformTarget>
<RuntimeIdentifier Condition=" '$(PlatformTarget)' == 'x86' ">win7-x86</RuntimeIdentifier>

so it works only for Windows and in order to execute the project you need to call dotnet run which rebuilds the project again, which does not work good for us (we perform dotnet $pathToDll which does not compile it again)

[AndreyAkinshin]

@adamsitnik, please check the appveyor build, it's red after your last commit.

[adamsitnik]

@AndreyAkinshin sorry!

btw the reason for fail:

Previously we were hardcoding x64 for .NET Core benchmarks. Now it's configurable.

But when the Platform is not specified we take the default value. The default is AnyCpu, but it's overwritten by EnvResolver, which registers the host process platform as the default (Register(EnvMode.PlatformCharacteristic, RuntimeInformation.GetCurrentPlatform);)

The problem here was that for this particular test we had classic .NET test runner, 32bit, which was trying to build and run 32bit .NET Core process on the machine without 32bit .NET Core sdk.

I was not sure if we should still register the host platform as default, but I decided to not break the behavior and leave it the way it is and just set the platform in explicit way for this particular test.

[AndreyAkinshin]

An idea about the "x86 vs x32" .NET Core problem: we can detect all available dotnet.exe (e.g. via where dotnet, it should be available on all modern versions of Windows). Next, we can check the architecture of each dotnext.exe (e.g. like this, it works perfectly for C:\Program Files\dotnet\dotnet.exe and C:\Program Files (x86)\dotnet\dotnet.exe on my Windows 10). Finally, we can use dotnet.exe which is matched to the user config (or print a message that says something like "sorry, we didn't find appropriate runtime"). @adamsitnik, what do you think?

[AndreyAkinshin]

I copy-pasted the last comment to https://github.com/dotnet/BenchmarkDotNet/issues/534, let's continue this discussion there.