You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be nice if <Nullable>enable</Nullable> was automatically set in the generated csproj. Recent .NET versions are pushing hard to making this the default everywhere (the billion dollar mistake), and I noticed it only required minor changes to enable this in my project after the fact.
Some things to take into account if you do this, though:
Entity fields such as BaseEntity.CreatedBy need to become string? so nullability is now explicit, and EF will make these fields non-null otherwise now. This also applies to fields in general, but this is probably what you want (non-null database field for non-nullable C# property).
.NET will start validating non-nullable DTO fields as Required in the API automatically; omitting these fields in the request body will generate Bad Request errors, which is probably what you want and doesn't happen currently (e.g. omitting a field in PUT will have the same effect as explicitly setting it to null, which was misleading to me the first time and probably will be to other clients, too).
Similarly, FooParametersDto needs to make Filters and SortOrder a string? or they will always be required.
Ironically, adding [Required] attribute (not automatically added currently) is still useful or the OpenAPI specification won't mark the field as required despite .NET validating them at runtime.
Every DTO with non-nullable fields will spawn warnings about the fields potentially being null because there is no constructor and they can be fetched through get without setting them first through set. With .NET 7 you can do e.g. public required string FirstName { get; set; } to fix this if you don't want to spawn constructors everywhere.
The text was updated successfully, but these errors were encountered:
It would be nice if
<Nullable>enable</Nullable>
was automatically set in the generatedcsproj
. Recent .NET versions are pushing hard to making this the default everywhere (the billion dollar mistake), and I noticed it only required minor changes to enable this in my project after the fact.Some things to take into account if you do this, though:
BaseEntity.CreatedBy
need to becomestring?
so nullability is now explicit, and EF will make these fields non-null otherwise now. This also applies to fields in general, but this is probably what you want (non-null database field for non-nullable C# property).Required
in the API automatically; omitting these fields in the request body will generate Bad Request errors, which is probably what you want and doesn't happen currently (e.g. omitting a field inPUT
will have the same effect as explicitly setting it tonull
, which was misleading to me the first time and probably will be to other clients, too).FooParametersDto
needs to makeFilters
andSortOrder
astring?
or they will always be required.[Required]
attribute (not automatically added currently) is still useful or the OpenAPI specification won't mark the field as required despite .NET validating them at runtime.null
because there is no constructor and they can be fetched throughget
without setting them first throughset
. With .NET 7 you can do e.g.public required string FirstName { get; set; }
to fix this if you don't want to spawn constructors everywhere.The text was updated successfully, but these errors were encountered: