-
Notifications
You must be signed in to change notification settings - Fork 10.3k
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.
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
Conversation
Confirmed that this works. Temporary work around can be removed when updating to new BDN. |
( | ||
// not using "net5.0", a workaround for https://github.com/dotnet/BenchmarkDotNet/pull/1479 | ||
targetFrameworkMoniker: "netcoreapp5.0", | ||
runtimeFrameworkVersion: default, |
There was a problem hiding this comment.
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.
A workaround for BDN bug caused by netcoreapp5.0->net5.0 moniker rebranding
The proper fix is available at: dotnet/BenchmarkDotNet#1479 but before we ship new BDN version to NuGet.org (most probably a matter of months) you can use this workaround.
@JamesNK
Fixes #22915