ProblemDetails: support resolving ProblemDetailsOptions from service collection

[khellang]

ProblemDetails: support resolving ProblemDetailsOptions from service collection

[sliekens]

Basic usage would then involve 2 lines of code instead of 1.

public void ConfigureServices(IServiceCollection services)
{
    services.AddProblemDetails();
}

public void Configure(IApplicationBuilder app)
{
    services.UseProblemDetails();
}

Although it might be possible to detect when no call to AddProblemDetails was made and fallback to the old behavior with Options.Create(0.

[khellang]

Yeah, I've gone back and forth on this. I thought about doing it, but I don't see any big advantage over the current solution. It's just more code (an extra call to services.AddProblemDetails()) to write, and the middleware doesn't really need to add any services. Want to convince me otherwise? 👼

[khellang]

Although it might be possible to detect when no call to AddProblemDetails was made and fallback to the old behavior with Options.Create(0.

I do this with the SpaFallback middleware;

Middleware/src/SpaFallback/SpaFallbackExtensions.cs

Lines 49 to 50 in d38a176

	// Make sure we signal that we've called AddSpaFallback.
	services.TryAddSingleton<SpaFallbackMarkerService>();

Middleware/src/SpaFallback/SpaFallbackExtensions.cs

Lines 65 to 76 in d38a176

	var marker = app.ApplicationServices.GetService<SpaFallbackMarkerService>();
	if (marker == null)
	{
	var message = new StringBuilder()
	.AppendLine($"Unable to find the required services for the {nameof(UseSpaFallback)} middleware to function correctly.")
	.AppendLine($"Make sure you call {AddServices} before calling {UseMiddleware}.")
	.AppendLine("This is typically done inside the ConfigureServices method in your Startup class.")
	.ToString();
	throw new InvalidOperationException(message);
	}

But it seems like it's a lot of hassle for no benefit, because the middleware really doesn't need any services injected (I don't view options as a "service").

[sliekens]

My issue started with the desire to have my problem configuration in a separate file.

First I created a static class for it.

public static class ProblemConfigurer
{
    public static void Configure(ProblemDetailsOptions options)
    {
        ...
    }
}

// usage
public void Configure(IApplicationBuilder app)
{
    services.UseProblemDetails(ProblemConfigurer.Configure);
}

Then I quickly realized that I need my own dependencies inside ProblemConfigurer. It's impossible to do that via DI since it's a static class. There is a workaround, but the code is not very pleasant.

// DI workaround
public void Configure(IApplicationBuilder app, IService1 dep1, IService2 dep2)
{
    services.UseProblemDetails(options => ProblemConfigurer.Configure(options, dep1, dep2));
}

Ultimately I'd like to convert my ProblemConfigurer to non-static and register it with DI so I can just have seamless dependency injection.

The benefit for me is being able to have a separate class that implements IConfigureOptions<ProblemDetailsOptions> and have the DI framework inject dependencies without having to write additional code.

[khellang]

Hmm. I guess I could find a way to support both, without breaking people. I.e. you won't have to call AddProblemDetails, but you could if you want to use DI for configuration.

[khellang]

Pushed v2.1.1. Allowed myself to make a tiny breaking change by obsoleting the old UseProblemDetails method since literally no one has downloaded the 2.0.0 package yet 😝

[sliekens]

Works great, thanks!