-
Notifications
You must be signed in to change notification settings - Fork 10.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No service for type 'Microsoft.AspNetCore.Server.Kestrel.Core.IHttpsConfigurationService' after upgrading to .NET 8 preview #48956
Comments
Could you provide a code sample or minimal repro of what you are trying to do? |
Here is a minimal repro:
program.cs:
|
The service is only added here, making UseHttps unusable without IWebHostBuilder:
Though you could provide your own implementation of IWebHostBuilder. Otherwise the service would have to be made public, or at least add a public IServiceCollection extension to unblock you. |
@Tratcher actually there's more. I need to also create an IHostEnvironment, KestrelMetrics, and an IMeterFactory:
it seems the ability to create a server without all the WebHostBuilder plumbing is impossible now. It's disappointing to see all these breaking changes making it difficult for us to migrate from .NET 7 to .NET 8. |
@timmydo it would be great if you could express why you're not using one of the documented paths for creating a server instance for testing? Why all of this manual code? |
This isn't how I'd create a new server if I got to start from scratch today--this is trying to show a minimal repro from an ASP.NET application that has been around longer than ASP.NET Core...it comes from a time where we had our own abstractions to support multiple different web servers, our own dependency injection library, our own middleware, etc. We want to be able to use parts of ASP.NET Core and Kestrel, so the way it was originally done was by using the core pieces we wanted and not just creating a default web host and all the extras that entailed--because we wanted the control and had a bunch of config/code in other places that needed to be preserved. Is it a deliberate decision to require web host builder for https scenarios going forward? |
We have documented ways (too many maybe) of creating a minimal web server, the most recent being: var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
await app.RunAsync();
I'd recommend finding a way to shift to using the hosting layer. There's no real golden path to using kestrel stand alone, it's a quite a bit of manual wire up. While we can and will fix the issues, the entry point to creating a kestrel sever will likely reuse most of these APIs under the covers. |
After some offline discussions, I think @timmydo was able to adopt |
Other things being equal, we would certainly prefer to maintain the invariant that code compiling against 7.0 should continue to compile, unmodified, against 8.0. Unfortunately, in this case, that's at odds with our goal of making HTTPS support opt-in to substantially reduce the size of some trimmed/AOT'd assemblies. As a result, anyone upgrading is going to have to write some new code. Given that, it seems reasonable to encourage anyone in that position to adopt the recommended and supported host builder approach, most conveniently through CreateDefaultBuilder, but alternatively through CreateSlimBuilder or CreateEmptyBuilder if they want maximal control. Especially given that this is the only request (I know of) for this functionality and that it's been resolved by successfully adopting a host builder, it seems reasonable to close this issue, even though the breaking change is regrettable. |
If you really, really don't want to use a host builder, it's actually possible to create a dummy one that will cause your service collection to be updated appropriately: internal static class KestrelHelper
{
public static IServiceCollection AddKestrel(this IServiceCollection serviceCollection, string applicationName, string contentRoot)
{
serviceCollection.AddSingleton<IHostEnvironment>(new MyHostEnvironment
{
ApplicationName = applicationName,
ContentRootPath = contentRoot
});
serviceCollection.AddSingleton<IMeterFactory, MyMeterFactory>();
var builder = new MyBuilder(serviceCollection);
builder.UseKestrel();
return serviceCollection;
}
private sealed class MyBuilder : IWebHostBuilder
{
private readonly IServiceCollection _serviceCollection;
public MyBuilder(IServiceCollection serviceCollection)
{
_serviceCollection = serviceCollection;
}
IWebHostBuilder IWebHostBuilder.ConfigureServices(Action<IServiceCollection> configureServices)
{
configureServices(_serviceCollection);
return this;
}
IWebHost IWebHostBuilder.Build() => throw new NotImplementedException();
IWebHostBuilder IWebHostBuilder.ConfigureAppConfiguration(Action<WebHostBuilderContext, IConfigurationBuilder> configureDelegate) => throw new NotImplementedException();
IWebHostBuilder IWebHostBuilder.ConfigureServices(Action<WebHostBuilderContext, IServiceCollection> configureServices) => throw new NotImplementedException();
string IWebHostBuilder.GetSetting(string key) => throw new NotImplementedException();
IWebHostBuilder IWebHostBuilder.UseSetting(string key, string value) => throw new NotImplementedException();
}
private sealed class MyHostEnvironment : IHostEnvironment
{
public string EnvironmentName { get => throw new NotImplementedException(); set => throw new NotImplementedException(); }
public string ApplicationName { get; set; }
public string ContentRootPath { get; set; }
public IFileProvider ContentRootFileProvider { get => throw new NotImplementedException(); set => throw new NotImplementedException(); }
}
private sealed class MyMeterFactory : IMeterFactory
{
public Meter Create(MeterOptions options) => new Meter(options);
public void Dispose() { }
}
} |
Is there an existing issue for this?
Describe the bug
Our existing application fails to startup:
Expected Behavior
Not throw an exception
Steps To Reproduce
We aren't using the web host builder. The new interface or given implementation does not appear to be public.
Exceptions (if any)
No response
.NET Version
8.0.100-preview.5.23303.2
Anything else?
f1bbdd4
@amcasey
The text was updated successfully, but these errors were encountered: