[nightly] Update dependencies from dotnet/installer

[dotnet-docker-bot]

No description provided.

[dotnet-docker-bot]

Discarded 8776be4: [nightly] Update dependencies from dotnet/installer

CI Status: 1:heavy_check_mark: (click to expand)

• ✔️ license/cla All CLA requirements met. Details

[dotnet-docker-bot]

Discarded a7998b0: [nightly] Update dependencies from dotnet/installer

CI Status: 1:heavy_check_mark: (click to expand)

• ✔️ license/cla All CLA requirements met. Details

[mthalman]

@jander-msft - A Monitor test is failing when running with the Preview 2 build. Can you investigate?

[jander-msft]

@jander-msft - A Monitor test is failing when running with the Preview 2 build. Can you investigate?

Sure thing, I'll investigate this today.

[jander-msft]

Something changed in ASP.NET Core that is now failing to start .NET Monitor regarding the lack of HTTPS certificate. .NET Monitor was written in such a way that Kestrel should not be automatically attempting to bind all of the endpoints and the tool itself does it manually so that the lack of HTTPS certificate doesn't bring down the process because the metrics endpoints should still be able to bind.

Unhandled exception: System.InvalidOperationException: Unable to configure HTTPS endpoint. No server certificate was specified, and the default developer certificate could not be found or is out of date.
To generate a developer certificate run 'dotnet dev-certs https'. To trust the certificate (Windows and macOS only) run 'dotnet dev-certs https --trust'.
For more information on configuring HTTPS see https://go.microsoft.com/fwlink/?linkid=848054.
   at Microsoft.AspNetCore.Hosting.ListenOptionsHttpsExtensions.<>c__DisplayClass10_0.<UseHttps>b__0()
   at System.Lazy`1.ViaFactory(LazyThreadSafetyMode mode)
--- End of stack trace from previous location ---
   at System.Lazy`1.CreateValue()
   at Microsoft.AspNetCore.Hosting.ListenOptionsHttpsExtensions.<>c__DisplayClass12_0.<UseHttps>b__0(ConnectionDelegate next)
   at Microsoft.AspNetCore.Server.Kestrel.Core.ListenOptions.Build()
   at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.<>c__DisplayClass29_0`1.<<StartAsync>g__OnBind|0>d.MoveNext()
--- End of stack trace from previous location ---
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindEndpointAsync(ListenOptions endpoint, AddressBindContext context, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.ListenOptions.BindAsync(AddressBindContext context, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.AnyIPListenOptions.BindAsync(AddressBindContext context, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.EndpointsStrategy.BindAsync(AddressBindContext context, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.AddressBinder.BindAsync(IEnumerable`1 listenOptions, AddressBindContext context, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.BindAsync(CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Server.Kestrel.Core.KestrelServerImpl.StartAsync[TContext](IHttpApplication`1 application, CancellationToken cancellationToken)
   at Microsoft.AspNetCore.Hosting.GenericWebHostService.StartAsync(CancellationToken cancellationToken)
   at Microsoft.Extensions.Hosting.Internal.Host.StartAsync(CancellationToken cancellationToken)
   at Microsoft.Diagnostics.Tools.Monitor.Commands.CollectCommandHandler.Invoke(CancellationToken token, String[] urls, String[] metricUrls, Boolean metrics, String diagnosticPort, Boolean noAuth, Boolean tempApiKey, Boolean noHttpEgress, FileInfo configurationFilePath)
   at Microsoft.Diagnostics.Tools.Monitor.Commands.CollectCommandHandler.Invoke(CancellationToken token, String[] urls, String[] metricUrls, Boolean metrics, String diagnosticPort, Boolean noAuth, Boolean tempApiKey, Boolean noHttpEgress, FileInfo configurationFilePath)
   at Microsoft.Diagnostics.Tools.Monitor.Program.<>c.<<CollectCommand>b__1_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Invocation.AnonymousCommandHandler.InvokeAsync(InvocationContext context)
   at System.CommandLine.Invocation.InvocationPipeline.<>c__DisplayClass4_0.<<BuildInvocationChain>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.CommandLineBuilderExtensions.<>c.<<RegisterWithDotnetSuggest>b__3_0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.CommandLineBuilderExtensions.<>c__DisplayClass0_0.<<CancelOnProcessTermination>b__0>d.MoveNext()
--- End of stack trace from previous location ---
   at System.CommandLine.Invocation.InvocationPipeline.<InvokeAsync>g__InvokeHandlerWithMiddleware|2_0(InvocationContext context)
   at System.CommandLine.Invocation.InvocationPipeline.InvokeAsync(IConsole console, CancellationToken cancellationToken)

cc @wiktork

[mthalman]

This PR looks related: dotnet/aspnetcore#46296. cc @amcasey

[amcasey]

cc @halter73 who may be able to psychically debug faster than I can investigate.

[amcasey]

@mthalman is there a simple way to repro that callstack locally?

[mthalman]

@mthalman is there a simple way to repro that callstack locally?

@jander-msft - Can you provide your simplest repro, ideally outside of Docker?

[amcasey]

Aside: Looks like we might need to handle dev17 here.

[amcasey]

I've managed to build dotnet-monitor.exe locally and I think the repro is just dotnet-monitor collect, but I still need to figure out how to reference a different set of aspnetcore binaries so I can observe and debug the failure.

[amcasey]

Think I got it. If anyone's following along:

Add a reference to src\Tools\dotnet-monitor\dotnet-monitor.csproj

<ItemGroup Condition="'$(ToolTargetFrameworks)' == 'net8.0'">
  <Reference Include="e:\aspnetcore\artifacts\bin\Microsoft.AspNetCore\Release\net8.0\Microsoft.AspNetCore.Server.Kestrel.Core.dll" />
</ItemGroup>

Build

.\build -architecture x64 -configuration debug

Run

artifacts\bin\dotnet-monitor\Debug\net8.0\dotnet-monitor.exe collect

Edit: I was able to repro the issue, but I turned out to be using the nightly build of kestrel and not my local binary. I won't look for a better way since we've already decided to revert.

[halter73]

Alright. I went looking for how the lack of a certificate was ignored on a per-endpoint basis, and found this scary Kestrel configuration callback 😨:

https://github.com/dotnet/dotnet-monitor/blob/7e76cf016cbccc82b7e8a91c724ddac58b0c5c15/src/Tools/dotnet-monitor/HostBuilder/HostBuilderHelper.cs#L134-L170

And where the exception is eagerly expected from the call to KestrelServerOptions.Listen() inside the configuration callback:

https://github.com/dotnet/dotnet-monitor/blob/7e76cf016cbccc82b7e8a91c724ddac58b0c5c15/src/Tools/dotnet-monitor/AddressListenResults.cs#L92-L113

Then I found an old issue I filed on behalf of @wiktork when he was working on dotnet-monitor (dotnet/aspnetcore#28120). It asks for a more first-class way to support this scenario. The suggestion at the time was preloading config, but really we just need a way to skip HTTPS binding if there's no certifcate.

Our best bet might be to preload config like the issue suggests. We're going to do it eventually anyway. Then maybe we go back to throwing from Listen(). It does risk locking in outdated config, but I'm not sure how likely that is. I feel like it's a niche use case, so we can consider changing dotnet-monitor if we come up with a better solution though. I doubt it represents anything a lot of other applications are doing, but who knows?

I think we should revert dotnet/aspnetcore#46296 for now while we figure out if there's a way to allow dotnet-monitor to preserve its existing behavior while fixing dotnet/aspnetcore#45801.

[jander-msft]

Alright. I went looking for how the lack of a certificate was ignored on a per-endpoint basis, and found this scary Kestrel configuration callback 😨

The scary callback is due to two aspects that we were working arround:

1. The allowing of individual endpoints to fail binding without taking down the whole server (e.g. UseHttps, catch, and move on). This is the one you've talked about and is referenced by Preload default Kestrel config before running Kestrel's configureOptions callback aspnetcore#28120
2. The tool always printed "Overriding address(es) '{addresses}'. Binding to endpoints defined via IConfiguration and/or UseKestrel() instead." because it was handling the bindings itself instead of letting Kestrel do it. While the warning is technically correct, it was perceived as scary to see that by a few folks, and it indicated something was wrong/misconfigured with the tool (when in reality nothing was wrong). I did work to effectively hide the "urls" configuration from Kestrel since we already did the binding ourselves in the callback. I'm completely open to alternatives to avoid this complicated configuration coordination but I don't want that warning to always appear.

[amcasey]

Revert is here: dotnet/aspnetcore#46868

[amcasey]

Revert is merged.

[dotnet-docker-bot]

Discarded 1cb744e: [nightly] Update dependencies from dotnet/installer