For context see:
We can address all of Allan's concerns by using the second method from the benchmark fork:
|
case RegisterEventBinderMethod.InvokeConfigOptions: |
|
var options = new SentryMauiOptions(); |
|
configureOptions?.Invoke(options); |
|
services.TryAddSingleton<SentryOptions>(options); // Ensure this doesn't get resolved again in AddSentry |
|
foreach (var eventBinder in options.DefaultEventBinders) |
|
{ |
|
eventBinder.Register(services); |
|
} |
|
break; |
That way people still setup the new integration as an extension on SentryOptions (i.e. from within the call to UseSentry) and we don't build a service provider to resolve the options. The time required to do this would be absolutely trivial, regardless of the container technology that people have chosen... and we can do this without creating any extra benchmarks.
For context see:
We can address all of Allan's concerns by using the second method from the benchmark fork:
sentry-dotnet/src/Sentry.Maui/SentryMauiAppBuilderExtensions.cs
Lines 88 to 96 in 7f64d50
That way people still setup the new integration as an extension on
SentryOptions(i.e. from within the call toUseSentry) and we don't build a service provider to resolve the options. The time required to do this would be absolutely trivial, regardless of the container technology that people have chosen... and we can do this without creating any extra benchmarks.