Stored proc with nullable string column throws SqlNullValueException under EF Core 8 + nullable enabled

[Brqqq]

Hi, I'd like some guidance on whether the following is expected behavior and what the recommended approach is.

Environment

• Reverse POCO Generator v3.14.0
• EF Core 8+ target
• Consuming project has <Nullable>enable</Nullable>
• Default settings (AllowNullStrings = false), stored-procedure generation enabled

I have this stored procedure to reproduce the issue:

CREATE PROCEDURE dbo.sp_NullableStringRepro AS
BEGIN
    SET NOCOUNT ON;
    SELECT CAST(NULL AS varchar(50)) AS SomeText;
END

This results in the following code

        public class sp_NullableStringReproReturnModel
        {
            public string SomeText { get; set; }
        }

        public List<sp_NullableStringReproReturnModel> sp_NullableStringRepro(out int procResult)
        {
            var procResultParam = new SqlParameter { ParameterName = "@procResult", SqlDbType = SqlDbType.Int, Direction = ParameterDirection.Output };
            const string sqlCommand = "EXEC @procResult = [dbo].[sp_NullableStringRepro]";
            var procResultData = Set<sp_NullableStringReproReturnModel>()
                .FromSqlRaw(sqlCommand, procResultParam)
                .ToList();

            procResult = (int) procResultParam.Value;
            return procResultData;
        }

When I call it, I get the following exception: System.Data.SqlTypes.SqlNullValueException: 'Data is Null. This method or property cannot be called on Null values.'

If I change the #nullable restore to #nullable disable in the generated models, EF Core interprets it correctly and everything works without throwing exceptions.

My understanding is:

• By default, nullable is turned on (as per project setting) for the generated model .cs file
• The // <auto-generated> in the generated file turns it off again
• #nullable restore turns it back on (as per project setting)
• EF Core then uses the nullability to do runtime sanity checks, which is what is causing my issue.

I can change the script so it writes #nullable disable instead. But I'm wondering if I'm thinking about this the right way or if there's a better solution that I'm missing

[sjh37]

Not expected behaviour - it's a bug in the generator, and #nullable disable is the right instinct but the wrong place to fix it (your edit is overwritten when the .tt regenerates).

What's happening: for table columns the generator emits .IsRequired(false) so EF Core guards NULLs. For stored-proc return models it doesn't - they're registered with only .HasNoKey(), so EF Core 8 decides whether a column can be NULL purely from the C# nullability of the property. Your project's <Nullable>enable</Nullable> makes public string SomeText a non-nullable reference, so EF reads it without a null check and throws. #nullable disable makes the property nullable-oblivious, which EF treats as nullable - hence it works.

Note AllowNullStrings = true will not fix this on its own (the return-model generator hardcodes string columns as non-nullable), so there's no current setting that solves it cleanly. I'll fix the generator so nullable SP return columns are emitted correctly.