Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exclude CS8618 for DbSet<T> in a derived DbContext class #45912

Closed
Youssef1313 opened this issue Jul 11, 2020 · 5 comments
Closed

Exclude CS8618 for DbSet<T> in a derived DbContext class #45912

Youssef1313 opened this issue Jul 11, 2020 · 5 comments

Comments

@Youssef1313
Copy link
Member

See this article from EF Core docs.

When nullable reference types are enabled, the C# compiler emits warnings for any uninitialized non-nullable property, as these would contain null. As a result, the common practice of defining a non-nullable DbSet on a context will now generate a warning. However, EF Core always initializes all DbSet properties on DbContext-derived types, so they are guaranteed to never be null, even if the compiler is unaware of this.

There is a workaround mentioned in the docs to add = null!, but I feel it's reasonable to exclude any public DbSet that exists in a class derived from DbContext by default.

Youssef1313 added a commit to Youssef1313/AskQ that referenced this issue Jul 11, 2020
@Dreamescaper
Copy link
Contributor

Dreamescaper commented Jul 11, 2020

I think that this issue doesn't belong here, should go to ef core repository.

As a workaround you can disable it for certain files via .editorconfig file.

@Youssef1313
Copy link
Member Author

@Dreamescaper How EF Core's team may be able to fix that? I think it should be excluded by the compiler (less noisy than disabling warning or adding = null!).

@Youssef1313
Copy link
Member Author

cc: @ajcvickers May you take a look?

@Dreamescaper
Copy link
Contributor

They can create DiagnosticSuppressor for this purpose.

@Youssef1313
Copy link
Member Author

@Dreamescaper Great. I didn't knew about it before, but it looks like the correct fix. I'll wait for @ajcvickers to move the issue to efcore repo

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants