In WebHost, there is IHostingStartup interface, see https://github.com/aspnet/Hosting/issues/1000.
Can we do something similar for generic host, something like below
C#
/// <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.
@davidfowl @Tratcher thoughts for 3.0?
I think we can do this for 3.0 yes
IMHO it would be great to also have support for the
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.
Is this still in scope for 3.0?
Is this still in scope for 3.0?
No, it's in the backlog.
@Tratcher do you know if the plan is to get this into 3.1 ? or sooner after v3.0 release ?
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.
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.
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.
IHostStartup interface to ....Hosting.AbstractionsHostingStartupAttribute class to ....Hosting.AbstractionsPreventHostingStartup, HostingStartupAssemblies, HostingStartupExcludeAssemblies from WebHostOptions to the Microsoft.Extensions.Hosting.HostOptions classExecuteHostingStartups from the class Microsoft.AspNetCore.Hosting.GenericWebHostBuilder to the ....Hosting.HostBuilder class@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.
Most helpful comment
Regarding the Needs Design label, can't we simply copy the functionality from
Microsoft.AspNetCore.Hosting? Only the parts required for theIHostStartup, i.e.IHostStartupinterface to....Hosting.AbstractionsHostingStartupAttributeclass to....Hosting.AbstractionsPreventHostingStartup,HostingStartupAssemblies,HostingStartupExcludeAssembliesfromWebHostOptionsto theMicrosoft.Extensions.Hosting.HostOptionsclassExecuteHostingStartupsfrom the classMicrosoft.AspNetCore.Hosting.GenericWebHostBuilderto the....Hosting.HostBuilderclass