ReSharper warning CS8669: nullable reference types inside Auto-generated code

[TimSirmovics]

When nullable reference types are enabled, the following ReSharper compiler warning is emitted:

Code inspection: The annotation for nullable reference types should only be used in code within a '#nullable' annotations context. Auto-generated code requires an explicit '#nullable' directive in source.

Can you add an explicit #nullable directive when nullable reference types are used?

[sjh37]

Hi @TimSirmovics

This is already handled. When AllowNullStrings = true, the generator adds #nullable enable to the top of every generated file (after the // <auto-generated> comment), which satisfies the CS8669 requirement for an explicit #nullable directive in auto-generated code.

See Generator/Generators/FileHeaderFooter.cs:

if (Settings.NeedsNullForgiving())
    header.AppendLine("#nullable enable");

If you're seeing this warning, make sure AllowNullStrings is set to true in your Database.tt file:

Settings.AllowNullStrings = true;

I fixed something like this recently, but I don't know whether it's in the latest release or pending the next one.
It would be worth checking the current version of the ttinclude file from the master branch of this repo.
Latest version not yet released: EF.Reverse.POCO.v3.ttinclude

Copy that version to your project and give it a go. Let me know how it goes. p.s there was a breaking change back in 3.12.0 which I tell you how to fix for your upgrade if you are using an older version here https://github.com/sjh37/EntityFramework-Reverse-POCO-Code-First-Generator/releases/tag/v3.12.0

[TimSirmovics]

Hi @sjh37,

My issue is even without wanting to use null strings, the generator still emits code with nullable reference types which raise this warning. All of the warnings are in the context / supporting classes and not the models themselves.

[sjh37]

I asked claude to take a look ;-)

It looks like the root cause is in the template (TemplateEfCore8.cs). Lines 82 and 678 hardcode string? in the generated code:

• string? ToString(); (interface definition)
• public override string? ToString() (context/supporting class)

These are emitted regardless of AllowNullStrings or NullableReverseNavigationProperties. Meanwhile, FileHeaderFooter.cs:22 only adds #nullable enable to the file header when NeedsNullForgiving() returns true (AllowNullStrings || NullableReverseNavigationProperties).

So when both flags are false, the generated context and supporting class files contain string? annotations but no #nullable enable directive, which is exactly what triggers CS8669 ("nullable annotation in auto-generated code requires explicit #nullable directive").

The fix is to make those two string? usages conditional - they should emit string when NeedsNullForgiving() is false. In Mustache template terms, you'd need to pass a boolean variable (something like NullableEnabled) and use {{#NullableEnabled}}?{{/NullableEnabled}} on the return type, or just always emit string there since ToString() returning string (non-nullable) is valid and won't cause warnings.

The simplest safe fix would be to just drop the ? from those two ToString() return types entirely - string (non-nullable) is a valid override of object.ToString() and won't generate warnings in either nullable or non-nullable contexts.

Would you be able to do that and check it works for you?

[TimSirmovics]

Hi @sjh37 ,

Could you point Claude at line 20736:
ValueTask<object?> FindAsync(Type entityType, object?[]? keyValues, CancellationToken cancellationToken);{{#newline}}

This is a nullable reference type annotation that is used exclusively of any options.