Skip to content

BDN workaround for netcoreapp5.0->net5.0 moniker rebranding #23000

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
JamesNK merged 1 commit into from
Jun 17, 2020
+22 −1
Merged

BDN workaround for netcoreapp5.0->net5.0 moniker rebranding #23000

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 22 additions & 1 deletion src/Shared/BenchmarkRunner/Program.cs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,10 @@
using System.Text;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Configs;
using BenchmarkDotNet.Jobs;
using BenchmarkDotNet.Running;
using BenchmarkDotNet.Toolchains.CsProj;
using BenchmarkDotNet.Toolchains.DotNetCli;

namespace Microsoft.AspNetCore.BenchmarkDotNet.Runner
{
Expand All @@ -26,7 +29,7 @@ private static int Main(string[] args)

AssignConfiguration(ref args);
var summaries = BenchmarkSwitcher.FromAssembly(typeof(Program).GetTypeInfo().Assembly)
.Run(args, ManualConfig.CreateEmpty());
.Run(args, GetConfig());

foreach (var summary in summaries)
{
Expand Down Expand Up @@ -57,6 +60,24 @@ private static int Main(string[] args)
return 0;
}

private static IConfig GetConfig()
{
#if NET5_0 || NETCOREAPP5_0
return ManualConfig.CreateEmpty()
.AddJob(Job.Default
.WithToolchain(CsProjCoreToolchain.From(new NetCoreAppSettings
(
// not using "net5.0", a workaround for https://github.com/dotnet/BenchmarkDotNet/pull/1479
targetFrameworkMoniker: "netcoreapp5.0",
runtimeFrameworkVersion: default,
Copy link
Copy Markdown
Member

@halter73 halter73 Jun 26, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JamesNK @adamsitnik When I was running benchmarks on net5.0, I got a MethodAccessException when trying to reference Encoding.Latin1:

OverheadJitting  1: 512 op, 386800.00 ns, 755.4688 ns/op

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.
 ---> System.MethodAccessException: Attempt by method 'Microsoft.AspNetCore.Server.Kestrel.Performance.Http1ConnectionBenchmark+<>c.<Setup>b__7_0(System.String)' to access method 'System.Text.Encoding.get_Latin1()' failed.
   at Microsoft.AspNetCore.Server.Kestrel.Performance.Http1ConnectionBenchmark.<>c.<Setup>b__7_0(String _) in F:\dev\aspnet\AspNetCore\src\Servers\Kestrel\perf\Kestrel.Performance\Http1ConnectionBenchmark.cs:line 39
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Infrastructure.HttpUtilities.GetRequestHeaderString(ReadOnlySpan`1 span, String name, Func`2 encodingSelector) in F:\dev\aspnet\AspNetCore\src\Servers\Kestrel\Core\src\Internal\Infrastructure\HttpUtilities.cs:line 146
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpRequestHeaders.Append(ReadOnlySpan`1 name, ReadOnlySpan`1 value) in F:\dev\aspnet\AspNetCore\src\Servers\Kestrel\Core\src\Internal\Http\HttpHeaders.Generated.cs:line 6686
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.OnHeader(ReadOnlySpan`1 name, ReadOnlySpan`1 value) in F:\dev\aspnet\AspNetCore\src\Servers\Kestrel\Core\src\Internal\Http\HttpProtocol.cs:line 522
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpParser`1.TryTakeSingleHeader(TRequestHandler handler, ReadOnlySpan`1 headerLine) in F:\dev\aspnet\AspNetCore\src\Servers\Kestrel\Core\src\Internal\Http\HttpParser.cs:line 342
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpParser`1.ParseHeaders(TRequestHandler handler, SequenceReader`1& reader)
   at Microsoft.AspNetCore.Server.Kestrel.Performance.Http1ConnectionBenchmark.ParseData() in F:\dev\aspnet\AspNetCore\src\Servers\Kestrel\perf\Kestrel.Performance\Http1ConnectionBenchmark.cs:line 91
   at Microsoft.AspNetCore.Server.Kestrel.Performance.Http1ConnectionBenchmark.LiveAspNet() in F:\dev\aspnet\AspNetCore\src\Servers\Kestrel\perf\Kestrel.Performance\Http1ConnectionBenchmark.cs:line 74
   at BenchmarkDotNet.Autogenerated.Runnable_0.WorkloadActionNoUnroll(Int64 invokeCount) in F:\dev\aspnet\AspNetCore\artifacts\bin\Microsoft.AspNetCore.Server.Kestrel.Performance\Release\net5.0\0a11fc5a-0daf-42c0-9c2d-b77a4ffb15f1\0a11fc5a-0daf-42c0-9c2d-b77a4ffb15f1.notcs:line 838
   at BenchmarkDotNet.Engines.Engine.RunIteration(IterationData data)
   at BenchmarkDotNet.Engines.EngineFactory.Jit(Engine engine, Int32 jitIndex, Int32 invokeCount, Int32 unrollFactor)
   at BenchmarkDotNet.Engines.EngineFactory.CreateReadyToRun(EngineParameters engineParameters)
   at BenchmarkDotNet.Autogenerated.Runnable_0.Run(IHost host, String benchmarkName) in F:\dev\aspnet\AspNetCore\artifacts\bin\Microsoft.AspNetCore.Server.Kestrel.Performance\Release\net5.0\0a11fc5a-0daf-42c0-9c2d-b77a4ffb15f1\0a11fc5a-0daf-42c0-9c2d-b77a4ffb15f1.notcs:line 164
   --- End of inner exception stack trace ---
   at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor, Boolean wrapExceptions)
   at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
   at BenchmarkDotNet.Autogenerated.UniqueProgramName.AfterAssemblyLoadingAttached(String[] args) in F:\dev\aspnet\AspNetCore\artifacts\bin\Microsoft.AspNetCore.Server.Kestrel.Performance\Release\net5.0\0a11fc5a-0daf-42c0-9c2d-b77a4ffb15f1\0a11fc5a-0daf-42c0-9c2d-b77a4ffb15f1.notcs:line 47

I knew we had workarounds in place to make "net5.0" work with BenchmarkDotNet, so I found this PR. I figured this kind of MethodAccessException was likely caused by a runtime framework version mismatch, so locally I changed runtimeFrameworkVersion: default, to runtimeFrameworkVersion: "5.0.0-preview.8.20323.9",.

Sure enough, this fixed it, but is there a better way to fix this than manually passing the runtimeFrameworkVersion in here? It wasn't the most obvious thing, and is a bit of a pain.

name: ".NET Core 5.0"
)))
.AsDefault());
#else
return ManualConfig.CreateEmpty();
#endif
}

private static int Fail(object o, string message)
{
_standardOutput?.WriteLine(_standardOutputText.ToString());
Expand Down