I am working in a .NET 6 application on Arch Linux. The code is open-source.
I am certain that ASPNETCORE_ENVIRONMENT
is set to Development
because I updated the code in my Program.cs
to be:
if (!app.Environment.IsDevelopment())
{
app.UseExceptionHandler("/Error");
// the default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
app.UseHsts();
}
else
{
Console.WriteLine("We are in development environment!!!");
}
And when I run the application with dotnet run --project Bejebeje.Mvc/Bejebeje.Mvc.csproj
I can see my above message.
In my appsettings.json
and appsettings.Development.json
I don't have any variables set.
I do have user-secrets set. When I run dotnet user-secrets list --project Bejebeje.Mvc
I get:
Sentry__SendDefaultPii = true
Sentry__MinimumEventLevel = Warning
Sentry__MinimumBreadcrumbLevel = Debug
Sentry__IncludeRequestPayload = true
Sentry__Dsn = https://[email protected]/blah
Sentry__DiagnosticsLevel = Error
Sentry__Debug = true
Sentry__AttachStackTrace = true
IdentityServerConfiguration__ClientSecret = blah
IdentityServerConfiguration__ClientId = blah
IdentityServerConfiguration__Authority = https://cognito-idp.eu-central-1.amazonaws.com/eu-central-blah/
ConnectionString = Server=localhost;Port=5432;Database=bejebeje;User Id=postgres;Password=admin;
Yet when I run the application with dotnet run --project Bejebeje.Mvc/Bejebeje.Mvc.csproj
I get:
We are in development environment!!!
info: Microsoft.Hosting.Lifetime[14]
Now listening on: https://localhost:5001
info: Microsoft.Hosting.Lifetime[14]
Now listening on: http://localhost:5000
info: Microsoft.Hosting.Lifetime[0]
Application started. Press Ctrl C to shut down.
info: Microsoft.Hosting.Lifetime[0]
Hosting environment: Development
info: Microsoft.Hosting.Lifetime[0]
Content root path: /home/j/code/bejebeje/Bejebeje.Mvc/
fail: Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware[1]
An unhandled exception has occurred while executing the request.
System.ArgumentException: Options.ClientId must be provided (Parameter 'ClientId')
at Microsoft.AspNetCore.Authentication.OpenIdConnect.OpenIdConnectOptions.Validate()
at Microsoft.AspNetCore.Authentication.RemoteAuthenticationOptions.Validate(String scheme)
at Microsoft.AspNetCore.Authentication.AuthenticationBuilder.<>c__DisplayClass4_0`2.<AddSchemeHelper>b__1(TOptions o)
at Microsoft.Extensions.Options.ValidateOptions`1.Validate(String name, TOptions options)
at Microsoft.Extensions.Options.OptionsFactory`1.Create(String name)
at Microsoft.Extensions.Options.OptionsMonitor`1.<>c__DisplayClass10_0.<Get>b__0()
at System.Lazy`1.ViaFactory(LazyThreadSafetyMode mode)
at System.Lazy`1.ExecutionAndPublication(LazyHelper executionAndPublication, Boolean useDefaultConstructor)
at System.Lazy`1.CreateValue()
at System.Lazy`1.get_Value()
at Microsoft.Extensions.Options.OptionsCache`1.GetOrAdd(String name, Func`1 createOptions)
at Microsoft.Extensions.Options.OptionsMonitor`1.Get(String name)
at Microsoft.AspNetCore.Authentication.AuthenticationHandler`1.InitializeAsync(AuthenticationScheme scheme, HttpContext context)
at Microsoft.AspNetCore.Authentication.AuthenticationHandlerProvider.GetHandlerAsync(HttpContext context, String authenticationScheme)
at Microsoft.AspNetCore.Authentication.AuthenticationMiddleware.Invoke(HttpContext context)
at Sentry.AspNetCore.SentryTracingMiddleware.InvokeAsync(HttpContext context) in /_/src/Sentry.AspNetCore/SentryTracingMiddleware.cs:line 106
at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)
It can't find the ClientId here. I even debugged in Rider, and I can see that when I go past that line, ClientId is indeed null
.
What am I missing? I've been struggling with this for the past 2 days and I can't figure out why my user secrets aren't being read.
CodePudding user response:
When using user-secrets
- you should separate sections with a colon (:
) instead of a double-underscore (__
).
It is a bit confusing, I know, but double underscores are used for environment variables, whereas user secrets are not actually environment variables.
You can see MSDN's examples reflect this.