Settings.UsePropertiesForStoredProcResultSets

Settings.UsePropertiesForStoredProcResultSets

Renders the result-set collections on a multi-result-set return model as properties instead of fields.

Type	bool
Default	false (fields)
Applies to	EF 6 and EF Core
Databases	SQL Server, the only one that discovers multiple result sets
In Database.tt?	Yes

What it does

A stored procedure returning more than one result set gets a wrapper class holding one collection per set. This setting decides whether those collections are fields or properties.

It has no effect on a procedure with a single result set, whose model is a flat class of properties either way. That is the detail that makes people think the setting is broken.

Example

dbo.GetCourseReport returns two result sets - the course, then its students.

Settings.UsePropertiesForStoredProcResultSets = false (default)

    public class GetCourseReportReturnModel
    {
        public class ResultSetModel1
        {
            public int CourseId { get; set; }
            public string Title { get; set; }
        }
        public List<ResultSetModel1> ResultSet1;
        public class ResultSetModel2
        {
            public int StudentId { get; set; }
            public string StudentName { get; set; }
        }
        public List<ResultSetModel2> ResultSet2;
    }

Settings.UsePropertiesForStoredProcResultSets = true

    public class GetCourseReportReturnModel
    {
        public class ResultSetModel1
        {
            public int CourseId { get; set; }
            public string Title { get; set; }
        }
        public List<ResultSetModel1> ResultSet1 { get; set; }
        public class ResultSetModel2
        {
            public int StudentId { get; set; }
            public string StudentName { get; set; }
        }
        public List<ResultSetModel2> ResultSet2 { get; set; }
    }

ResultSet1 and ResultSet2 gain { get; set; }. The nested ResultSetModel classes are unchanged - their members were always properties.

When to use it

Turn it on if anything reflects over the model. Public fields are invisible to a great deal of .NET:

• System.Text.Json ignores fields by default. Serialise one of these models and you get {}. That is the single most common reason to reach for this setting.
• Most object mappers, model binders and validation frameworks work on properties only.
• Data binding in WPF, WinForms and Blazor requires properties.

Leave it off if the models are consumed directly in C# and nothing reflects over them. Fields are the historical default and changing it is a breaking change for anyone using the generated types.

Realistically, true is the better default for new code and the setting is only false for backwards compatibility.

Gotchas

Single-result-set procedures are unaffected. Their model is a flat class whose members are already properties. If you turned this on and nothing changed, that is why.

It does not touch the columns inside the result sets. Those are properties in both modes.

Changing it is a breaking change for consumers only in the sense that reflection-based code starts working. Ordinary field access and property access look identical at the call site.

Multiple identical result sets may be merged before this applies. See Settings.MergeMultipleStoredProcModelsIfAllSame, which can collapse a "multiple result set" procedure into a single-result-set one - at which point this setting stops having anything to do.

See also

• Settings.MergeMultipleStoredProcModelsIfAllSame
• Settings.StoredProcedureReturnModelRename - naming the wrapper class
• Stored Procedure Return Model Errors - when no model can be discovered at all
• Settings Reference