Remove ConfigureFromConfigurationOptions<T> from Sentry.Extensions.Logging

[jamescrosswell]

#skip-changelog

This change shouldn't impact SDK users at all.

Configure the new source generators

Adding the new source generators is simple enough - we can put something like the following in the respective *.csproj files (simplified somewhat):

  <PropertyGroup Condition="'$(FrameworkSupportsAot)' == 'true'">
    <IsAotCompatible>true</IsAotCompatible>
    <EnableConfigurationBindingGenerator>true</EnableConfigurationBindingGenerator>
  </PropertyGroup>

  ...

  <ItemGroup Condition="$(IfItsNotAlreadyIncludedAndFrameworkSupportsAot)">
    <PackageReference Include="Microsoft.Extensions.Configuration.Binder" Version="8.0.0-rc.2.23479.6" />
  </ItemGroup>

Remove ConfigureFromConfigurationOptions classes

We then need to remove the ConfigureFromConfigurationOptions<TOptions> classes we're using:

sentry-dotnet/src/Sentry.Extensions.Logging/SentryLoggingOptionsSetup.cs

Lines 6 to 12 in 3d0eb8b

	internal class SentryLoggingOptionsSetup : ConfigureFromConfigurationOptions<SentryLoggingOptions>
	{
	public SentryLoggingOptionsSetup(
	ILoggerProviderConfiguration<SentryLoggerProvider> providerConfiguration)
	: base(providerConfiguration.Configuration)
	{ }
	}

These aren't actually doing much. The SentryLoggingOptionsSetup here gets an ILoggerProviderConfiguration via dependency injection and uses that for the configuration binding. We can do the same with:

sentry-dotnet/src/Sentry.Extensions.Logging/SentryLoggingOptionsSetup.cs

Lines 11 to 26 in 9f616f1

	internal class SentryLoggingOptionsSetup : IConfigureOptions<SentryLoggingOptions>
	{
	private readonly IConfiguration _config;
	public SentryLoggingOptionsSetup(ILoggerProviderConfiguration<SentryLoggerProvider> config)
	{
	ArgumentNullException.ThrowIfNull(config);
	_config = config.Configuration;
	}
	public virtual void Configure(SentryLoggingOptions options)
	{
	ArgumentNullException.ThrowIfNull(options);
	_config.Bind(options);
	}
	}

At that point however, we get a bunch of SYSLIB1100 and SYSLIB1101 errors, because the configuration binding source generators don't know how to handle lots of the members of the SentryOptions class. It struggles with custom types like SubstringOrRegex, it fails completely with members of type Func or Action and even then, it creates code with a bunch of nullability warnings. In the technical spikes we did, we couldn't overcome any of these when binding to the SentryOptions type.

Solution

The workaround that is used in this PR is to create a much simpler BindableSentryOptions class that won't trip up the configuration binding source generators . This class uses nullable primitives like string? instead of SubstringOrRegexPattern and then takes care of any conversions from those string values to the more complex types we actually use, when applying that BindableSentryOptions type to the actual SentryOptions.

sentry-dotnet/src/Sentry.Extensions.Logging/SentryLoggingOptionsSetup.cs

Lines 8 to 26 in 8ca7fd7

	internal class SentryLoggingOptionsSetup : IConfigureOptions<SentryLoggingOptions>
	{
	private readonly IConfiguration _config;
	public SentryLoggingOptionsSetup(ILoggerProviderConfiguration<SentryLoggerProvider> config)
	{
	ArgumentNullException.ThrowIfNull(config);
	_config = config.Configuration;
	}
	public void Configure(SentryLoggingOptions options)
	{
	ArgumentNullException.ThrowIfNull(options);
	var bindable = new BindableSentryLoggingOptions();
	_config.Bind(bindable);
	bindable.ApplyTo(options);
	}
	}

For posterity

Some discussions kicked off in the dotnet/runtime repo:

• Telling Configuration-binding source generator to ignore certain members dotnet/runtime#94651
• Custom types with the Configuration-binding source generator dotnet/runtime#94686

Issues that are relevant to alternative potential solutions in the future:

• Extensibility for Configuration Binding Source Generator dotnet/runtime#83599
• ConfigurationBinder source generator generates code with the wrong nullable annotations dotnet/runtime#94105

[bitsandfoxes]

I'm fine with having this since it's not user-facing or breaking and unblocks us from moving forward. But we really need to figure out a way to source-generate the BindingOptions once we can confirm this as the working solution.