asp.net's configuration parsing puts null into non-nullable variables #45045
Comments
|
This is expected. Nullable is a compile-time only aid, it does not affect the application at runtime. Configuration is bound dynamically at runtime. Note the configuration and options APIs live in the runtime repo. I'll transfer this. |
Dotnet-GitSync-Bot
added
the
untriaged
|
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
|
Tagging subscribers to this area: @maryamariyan Issue DetailsDescribe the bugIf I make my code parse a custom configuration section in a To Reproducepublic Startup(IConfiguration configuration)
{
this.Configuration = configuration;
}
public IConfiguration Configuration { get; }
// This method gets called by the runtime. Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
services.Configure<MySettings>(this.Configuration.GetSection("MySettings"));
var mySettings= this.Configuration
.GetSection("MySettings")
.Get<LandingPageSettings>();Add any reference type to MySettings and observe that the parsing does not fail and fills the non-nullable variable with null. I didn't find anything related in dotnet/aspnetcore#5680 so I created this Issue. This might be caused by #1256, if you are using their parser. Does asp.net have a way of parsing configs that honors the not-null safety? Further technical details
|
|
@Tratcher as mentioned in #1256, entity framework's runtime behaviour is affected by nullable, so there must be some way to do different things depending on whether a type is nullable or not. Is there any |
|
ASP Options pattern has a means to configure validation https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration/options?view=aspnetcore-5.0#options-validation |
|
cc: @safern |
|
Sorry for the delay on responding. Unfortunately, at the moment we don't have an API that can tell us whether a member is a nullable reference type as the underlying type at runtime is the same for non-nullable as for nullable types, the only thing that changes is that the compiler emits metadata in order to capture the nullability. However this metadata is hard to read as it has a lot of edge cases, so in order to support this we would need a proper API that exposes this information via Reflection for example: #29723 -- until we have that API in place, we can't support this without a huge investment on implementing logic to read this metadata, which just seems overkill as the compiler could change the way metadata is represented at any time. However, I think that if we end up using source generators at compile time, we could get information about nullable reference types for the POCO an app is trying to bind to, and with that info, roslyn could tell us if the type has nullable annotations or not. We currently have this to investigate how source generators could help the binding story: #44493 |
|
Hi it looks to me like this API is now included in dotnet #29723 is there a way to turn this check on? Thank you :) |
Describe the bug
If I make my code parse a custom configuration section in a
<Nullable>enable</Nullable>project, it fills non-nullable references with null values instead of throwing an exception.To Reproduce
Add any reference type to MySettings and observe that the parsing does not fail and fills the non-nullable variable with null.
I didn't find anything related in dotnet/aspnetcore#5680 so I created this Issue. This might be caused by #1256, if you are using their parser.
Does asp.net have a way of parsing configs that honors the not-null safety?
Further technical details
dotnet --infoThe text was updated successfully, but these errors were encountered: