mcmonkey
mcmonkey
CC#
Created by mcmonkey on 10/9/2023 in #help
[Solved] WebApplication.CreateBuilder lockup in some Linux envs
the complaint about the mess was more related to the hours i spent digging through Builders that build before the build call through 12 layers of FactoryBuilderFactorySourceProviderBuilder oop hellscape
33 replies
CC#
Created by mcmonkey on 10/9/2023 in #help
[Solved] WebApplication.CreateBuilder lockup in some Linux envs
read the config file i get, the filewatch is the part that monitors for changes, and that should not be present in a production env, only dev (you don't do on-the-fly fiddling with config files in production!)
33 replies
CC#
Created by mcmonkey on 10/9/2023 in #help
[Solved] WebApplication.CreateBuilder lockup in some Linux envs
I had to do ungodly things involving manual fake-instrumentation and heavy reflection (why must all the relevant code be private/internal???) but i tracked it down: I was slightly off thinking it was Build(), it was actually the line above, WebApplication.CreateBuilder(), which redirects to new WebApplicationBuilder() which internally calls new HostApplicationBuilder(), which internally calls HostingHostBuilderExtensions.ApplyDefaultAppConfiguration(), which calls Configuration.AddJsonFile("appsettings.json", optional: true, reloadOnChange: reloadOnChange) and then again with $"appsettings.{env.EnvironmentName}.json". The delay is constrained to the first of the two calls (AppSettings) and is not repeated in the second (EnvName). Adding these files next to the executable does not change the delay. This does some stuff and then calls configuration.Add(source) which calls IConfigurationProvider provider = source.Build(configuration) which calls new JsonConfigurationProvider which calls source.FileProvider.Watch(source.Path) which locks up in short: File watchers lock up in some environments, and for some horrible reason AspNetCore registers a filewatcher to look for appsettings.json changing, even if you're in Production environment. Also for some other horrible reason CreateBuilder, which, yknow, creates a builder... does all the building, registering of file system attachments, etc. which is aggressively not what a Builder should be doing before you call Build. So the solution workaround is: Environment.SetEnvironmentVariable("ASPNETCORE_hostBuilder:reloadConfigOnChange", "false") before you call CreateBuilder The solution would be MS fixing the utter mess in the aspnetcore codebase. Argh.
33 replies
CC#
Created by mcmonkey on 10/9/2023 in #help
[Solved] WebApplication.CreateBuilder lockup in some Linux envs
that's the call that has a significant lockup time. No logs are given until after it's completed and other code is executing
33 replies
CC#
Created by mcmonkey on 10/9/2023 in #help
[Solved] WebApplication.CreateBuilder lockup in some Linux envs
Microsoft.AspNetCore.Builder.WebApplicationBuilder.Build()
33 replies
CC#
Created by mcmonkey on 10/9/2023 in #help
[Solved] WebApplication.CreateBuilder lockup in some Linux envs
The SetMinimumLevel call does work, and provides detailed debug logs for most things - just not the Build() call
33 replies
CC#
Created by mcmonkey on 10/9/2023 in #help
[Solved] WebApplication.CreateBuilder lockup in some Linux envs
MinimumLevel refers to the lowest level of logging that is shown, setting to Trace causes all debugging, Trace and up, to show. a Default level would one that is used when another level is not specified
33 replies
CC#
Created by mcmonkey on 10/9/2023 in #help
[Solved] WebApplication.CreateBuilder lockup in some Linux envs
yeah, uh, so... how? As mentioned above, builder.Logging.SetMinimumLevel(LogLevel) with even Trace set outputs nothing for the Build() call
33 replies