Issues moving to PAR

[Cerebellum90]

Which version of Duende IdentityServer are you using?
7.0.1

Which version of .NET are you using?
8.0

Describe the bug
We previously used AddAuthorizationParametersMessageStore with a custom querystring implementation.
Since IdentityServer version 7.x, the IAuthorizationParametersMessageStore is deprecated, in favor of using PAR.
Now that we're trying to implement PAR, we ran into the folowing issue.
We removed the line of .AddAuthorizationParametersMessageStore<> in our IdentityServer configuration, but runtime we receive this error on the "connect/authorize?client_id=" path;

StructureMapConfigurationException: No default Instance is registered and cannot be automatically determined for type 'Duende.IdentityServer.Stores.IAuthorizationParametersMessageStore'

There is no configuration specified for Duende.IdentityServer.Stores.IAuthorizationParametersMessageStore

1.) new AuthorizeEndpoint(Default of IEventService, Default of ILogger, Default of IdentityServerOptions, Default of IAuthorizeRequestValidator, Default of IAuthorizeInteractionResponseGenerator, Default of IAuthorizeResponseGenerator, Default of IUserSession, Default of IConsentMessageStore, Default of IAuthorizationParametersMessageStore)
2.) Duende.IdentityServer.Endpoints.AuthorizeEndpoint
3.) Instance of Duende.IdentityServer.Endpoints.AuthorizeEndpoint
4.) Container.GetInstance(Duende.IdentityServer.Endpoints.AuthorizeEndpoint)
5.) Container.TryGetInstance(Duende.IdentityServer.Endpoints.AuthorizeEndpoint)

The client configuration has the property RequirePushedAuthorization set to true.
Our first hunch was that StructureMap (our DI framework) wasn't able to find this instance. We made sure all the Duende.* assemblies are included.
Any suggestions for this issue?
Thanks in advance,
Lars

[Cerebellum90]

Additional research from our side, it appears StructureMap indeed has issues handling constructors with default values, and is not able to ignore those.
Surely an other DI framework that supports this will be a solution, but currently this is a development standard that we have for now.

[RolandGuijt]

IdentityServer internally uses a pattern of dependency injection in which services can be optional, and when an optional service is not present, a null value for that service is used. This pattern is supported by the default service provider implementation in ASP.NET - the Microsoft.Extensions.DependencyInjection.ServiceProvider. However some other service provider implementations, such as StructureMap, don't allow this kind of injection.

Our recommendation is to use the default service provider instead of StructureMap, but you already mentioned StructureMap is the standard in your org.

We're considering changing how we handle optional dependencies in a future release, tracked in issue #1520 here: DuendeSoftware/IdentityServer#1520

[Cerebellum90]

Dear Roland,
Thank you for considering an other way of handling optional depencencies. We'll follow that issue for further news.
for now we'll wait on moving over to PAR.