You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the proposed problem details changes in aspnetcore 7.0, does this effectively kill your library? Or do you still see usages of it? Personally I think the exception mapping alone is a reason to stick with this library and I'm not sure the proposed API shape covers those cases (at least as easily as here)
I ask mainly because the current proposed API includes extension methods for IServiceCollection that look like they are going to conflict with the ones this library offers. Any of us that wish to stick with your version would need to fully qualify the extension class name since we'd already be likely to have Microsoft.Extensions.DependencyInjection namespace already imported.
If you think there's still going to be a valid use case for this library, might I suggest offering an additional set of overloads of AddProblemDetails with a slightly different name?
The text was updated successfully, but these errors were encountered:
Personally I think the exception mapping alone is a reason to stick with this library and I'm not sure the proposed API shape covers those cases (at least as easily as here)
@pinkfloydx33 can you share what are the most useful mapping options that you are using? As I mentioned in the original proposal, I would like to have a follow up issue for the Exception Handler middleware
If you think there's still going to be a valid use case for this library, might I suggest offering an additional set of overloads of AddProblemDetails with a slightly different name?
The proposed public API does not add anything other than services that can be used by other parts of the framework (eg.: Middleware or filters), of course the implementation will update some of those middleware to use it, if that will cause a lot of confusion/conflict, we can easily accept a different name there, if we find one :)
As it turns out, there are also two middleware classes provided: UseExceptionHandler() and UseStatusCodePages() which will make sure the result is in the ProblemDetails format. I only just tried it out quickly, so I am not sure if it completely can replace this middleware, but it looks promising.
With the proposed problem details changes in aspnetcore 7.0, does this effectively kill your library? Or do you still see usages of it? Personally I think the exception mapping alone is a reason to stick with this library and I'm not sure the proposed API shape covers those cases (at least as easily as here)
I ask mainly because the current proposed API includes extension methods for
IServiceCollection
that look like they are going to conflict with the ones this library offers. Any of us that wish to stick with your version would need to fully qualify the extension class name since we'd already be likely to haveMicrosoft.Extensions.DependencyInjection
namespace already imported.If you think there's still going to be a valid use case for this library, might I suggest offering an additional set of overloads of
AddProblemDetails
with a slightly different name?The text was updated successfully, but these errors were encountered: