Add support for IHostingStartup/IHostStartup in generic host

[chuanboz]

In WebHost, there is IHostingStartup interface, see aspnet/Hosting#1000.

Can we do something similar for generic host, something like below

/// <summary>
    /// Represents platform specific configuration that will be applied to a <see cref="IHostBuilder"/> when building an <see cref="IHost"/>.
    /// </summary>
    public interface IHostStartup
    {
        /// <summary>
        /// Configure the <see cref="IHostBuilder"/>.
        /// </summary>
        /// <remarks>
        /// Configure is intended to be called before user code, allowing a user to overwrite any changes made.
        /// </remarks>
        /// <param name="builder"></param>
        void Configure(IHostBuilder builder);
    }

I will need this to execute some platform specific logic for integration testing with Service Fabric; I could define my own interface and get it work, but it would be useful if such concept could be generic in the generic host.

[muratg]

@davidfowl @Tratcher thoughts for 3.0?

[davidfowl]

I think we can do this for 3.0 yes

[grahamehorner]

IMHO it would be great to also have support for the

• HostingStartupAssemblies
• HostingStartupExcludeAssemblies

similar to the WebHost so a developer can inject assemblies that register/configure services prior to creation of the Host and/or IHostedService, BackgroundService without explicitly referencing/changing code.

[chuanboz]

Is this still in scope for 3.0?

[Tratcher]

Is this still in scope for 3.0?

No, it's in the backlog.

[grahamehorner]

@Tratcher do you know if the plan is to get this into 3.1 ? or sooner after v3.0 release ?

[Tratcher]

We haven't made plans for 3.1 yet, and it's not clear how high a priority this scenario is, we've only heard interest from a few people.

[fredrikhr]

Use case: Azure Pipelines (and other CIs) have their own syntax for parsing warnings and errors.

If we had IHostingStartup an Azure Pipelines logger assembly could just be injected using the .NET Startup Hooks and then you could run dotnet tools that use the generic host (e.g. together with the Hosting package from dotnet/command-line-api ) setup logging.

Point is under normal running the tool would log using normal console logger. In Azure Pipelines the output would actually highlight warnings and errors in the Azure Pipelines Build summary.

I actually do something quite similar for my .NET Core building tasks. I pass a custom MSBuild logger assembly as an argument to all .NET Core tasks. But the principle is very similar.

[fredrikhr]

Regarding the Needs Design label, can't we simply copy the functionality from Microsoft.AspNetCore.Hosting? Only the parts required for the IHostStartup, i.e.

• Add the IHostStartup interface to ....Hosting.Abstractions
• Add the HostingStartupAttribute class to ....Hosting.Abstractions
• Add properties PreventHostingStartup, HostingStartupAssemblies, HostingStartupExcludeAssemblies from WebHostOptions to the Microsoft.Extensions.Hosting.HostOptions class
• Add and call the method ExecuteHostingStartups from the class Microsoft.AspNetCore.Hosting.GenericWebHostBuilder to the ....Hosting.HostBuilder class

[grahamehorner]

@couven92 this seems on the face of it what is needed, and this would definitely assist in helping building a flexible/plugin host and dynamic configuration of services prior to the bootstrapping of services; I'm wondering if this type of process (dynamic loading of assembly) should verify that the assembly is signed using the a digital key and if the host trusts the signed key?

which in itself opens up a few questions around the current implementation in the Microsoft.AspNetCore.Hosting namespace/assembly.

[ElanHasson]

Any updates on this item?

[ElanHasson]

cc: @davidfowl @Tratcher

I made an implementation that mirrors that in WebHostBuilder, complete with HostingStartupAssemblies and
HostingStartupExcludeAssemblies support. Here is a repo: https://github.com/ElanHasson/GenericHostHostingStartup

After further inspection I don't think it is a straightforward as just adding those methods. IMO the better implementation would be to support it in Host versus WebHost as @fredrikhr stated above.

Also, moving HostingStartupAttribute and friends over to Microsoft.Extensions.Hosting.Abstractions would be a breaking change.

I'm happy to make changes and send a PR once design consensus is achieved.

[3GDXC]

@davidfowl @Tratcher any updates on this? it's something that I'd like to use; but not sure if it's work implementing myself or if a extension from the team is coming/available or on backlog?

[eerhardt]

I'm closing this issue as this isn't an approach we are going to take.

Instead, in 7.0 the plan is to implement #61634, which eliminates the need for Startup methods. And instead, the startup logic will look more like the ASP.NET Minimal APIs (which don't have Startup methods anymore either).