[API Proposal]: Decouple ValidateOnStart from Hosting

[tekian]

Usage of ValidateOnStart() today is located in the Microsoft.Extensions.Hosting assembly\package. This is problematic as it greatly inflates dependency tree of packages that need to validate their options eagerly when the hosting package is not otherwise needed. The ValidateOnStart() functionality should be moved to the Microsoft.Extensions.Options package.

In order for a host to call a "Validate()" method, a new public interface needs to be added, called IValidateOnStart here. This interface will be injected by the ValidateOnStart() functionality and then obtained by a host (for the default host, in the Microsoft.Extensions.Hosting assembly) with a call to GetService<IValidateOnStart>() in order to trigger the validation during startup.

The new interface located in the Microsoft.Extensions.Options assembly:

namespace Microsoft.Extensions.Options
{
+    public interface IValidateOnStart
+    {
+        void Validate();
+   }
}

The existing ValidateOnStart() extension method is located on the Microsoft.Extensions.DependencyInjection.OptionsBuilderExtensions extension class in the Microsoft.Extensions.Hosting assembly. The Microsoft.Extensions.Hosting assembly needs to forward this to the Microsoft.Extensions.Options assembly:

+[assembly: System.Runtime.CompilerServices.TypeForwardedTo(
+    typeof(Microsoft.Extensions.DependencyInjection.OptionsBuilderExtensions))]

Original request

Background and motivation

Usage of ValidateOnStart today is tightly coupled with Microsoft.Extensions.Hosting package. The call registers both ValidationHostedService and instructs ValidateOnStart infrastructure to validate T-type upon startup. This is problematic as it greatly inflates dependency tree of packages that need to validate their options eagerly.

Following measures should be considered:

• Move ValidateOnStart to Microsoft.Extensions.Options package. This decouple registration from implementation. Code that expresses the desire for eager validation doesn't involve registration of ValidationHostedService in the same call. The new API enables a cleaner separation of concern.
• Incorporate ValidationHostedService into Host bootstrapping as a shared option infrastructure. It becomes part of default Host and doesn't need to be registered with every ValidateOnStart call.

API Proposal

namespace Microsoft.Extensions.Options
{
    public static class OptionsBuilderExtensions
    {
        public static OptionsBuilder<TOptions> ValidateOnStart<TOptions>(this OptionsBuilder<TOptions> builder) 
            where TOptions : class;
    }

(Shape of the API remains the same)

API Usage

(Usage of the API remains the same.)

Alternative Designs

No response

Risks

Moving types around.

Tagging subscribers to this area: @dotnet/area-extensions-options
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and motivation

Usage of ValidateOnStart today is tightly coupled with Microsoft.Extensions.Hosting package. The call registers both ValidationHostedService and instructs ValidateOnStart infrastructure to validate T-type upon startup. This is problematic as it introduces cyclical dependencies and greatly inflates dependency tree of packages that need to validate their options eagerly.

Following measures should be considered:

• Move ValidateOnStart to Microsoft.Extensions.Options package. This decouple registration from implementation. Code that expresses the desire for eager validation doesn't involve registration of ValidationHostedService in the same call. The new API enables a cleaner separation of concern.
• Incorporate ValidationHostedService into Host bootstrapping as a shared option infrastructure. Implementation becomes part of default Host and doesnt need to be registered with every ValidateOnStart` call.

API Proposal

namespace Microsoft.Extensions.Options
{
    public static class OptionsBuilderExtensions
    {
        public static OptionsBuilder<TOptions> ValidateOnStart<TOptions>(
              this OptionsBuilder<TOptions> builder, 
              bool validateOnStart = true) where TOptions : class;
    }

(Shape of the API remains the same)

API Usage

(Usage of the API remains the same.)

Alternative Designs

No response

Risks

Moving types around.

Author:	tekian
Assignees:	-
Labels:	api-suggestion, area-Extensions-Options
Milestone:	-

[tarekgh]

CC @joperezr @geeknoid @davidfowl

[eerhardt]

See #47821 (comment) for some reasons why it was originally done this way.

Maybe Hosting needs an IStartupService enumerable service that gets resolved and all of them notified on start of the Host. My suggestion in the above conversation was a hook in the DI container (to know when the container was built), but that was rejected because we can't rely on the specifics of our DI container implementation. It would have to be a feature across all DI implementations for us to take advantage of it.

[tekian]

@eerhardt Thanks for the context. What would be the difference between IStartupService and IHostedService? Regardless of which of the two it would use, I believe "the desire to validate options eagerly" can be safely de-coupled from "implementation that performs it". We could have AddValidateOnStart(this IServiceCollection... inside Microsoft.Extensions.Hosting package that would add the service. And ValidateOnStart(this IOptionsBuilder... would be in Microsoft.Extensions.Options.

[eerhardt]

What would be the difference between IStartupService and IHostedService?

The difference would be that it wouldn’t need to be kept alive for the entire process just to call a no-op Stop method on it during shutdown. It would just get created, notified, and disposed during Start.

[ericstj]

@tekian can you help me understand the problem statement here? I see

This is problematic as it greatly inflates dependency tree of packages that need to validate their options eagerly.

Does this mean you are able to accomplish your goals today but you end up depending on more packages than you'd like? How does this correspond to the customer experience?