RevEng: Always scaffold HasPrecision for decimal columns in SQL Server

[yykkibbb]

• I've read the guidelines for contributing and seen the walkthrough
• I've posted a comment on an issue with a detailed description of how I am planning to contribute and got approval from a member of the team
• The code builds and tests pass locally (also verified by our automated build checks)
• Commit messages follow this format
• Tests for the changes have been added (for bug fixes / features)
• Code follows the same patterns and style as existing code in this repo

Summary

Make the "always scaffold HasColumnType for decimal" behavior SQL Server provider-specific, rather than the current approach where decimal(18,2) (default precision/scale) produces no configuration — causing runtime warnings about unspecified decimal column types.

Approach

Following the AnnotationCodeGenerator / SqlServerAnnotationCodeGenerator pattern:

1. Move IScaffoldingTypeMapper, TypeScaffoldingInfo, and ScaffoldingTypeMapper from EFCore.Design to EFCore.Relational so that provider projects can extend them
2. Add ShouldForceColumnType(Type) virtual hook to ScaffoldingTypeMapper (returns false by default), allowing providers to force HasColumnType scaffolding for specific CLR types even when the store type matches the default
3. Create SqlServerScaffoldingTypeMapper that overrides ShouldForceColumnType to return true for decimal, and register it in SqlServerDesignTimeServices

Behavior change

Case	Before	After
decimal(18,2) (default)	Nothing scaffolded → runtime warning	HasColumnType("decimal(18, 2)")
decimal(14,3) (non-default)	HasPrecision(14, 3)	HasColumnType("decimal(14,3)")
numeric(17,4)	HasColumnType("numeric(17,4)")	No change
Other providers (SQLite, etc.)	No change	No change

Fixes #12241

[yykkibbb]

@dotnet-policy-service agree

[yykkibbb]

Hi @roji, @ajcvickers, @smitpatel, @bricelam — I'd be grateful if any of you could take a look at this PR when you have a chance.

I'm fairly new to contributing to this project, but I'm eager to learn and do my best to help. If there's anything that needs to be adjusted or improved, I'm happy to make changes.

Thank you so much for your time

[AndriySvyryd]

It's preferable to just generate HasPrecision(, ) when possible.

[ErikEJ]

@AndriySvyryd That will require you to depend on the Abstractions package

[AndriySvyryd]

@ErikEJ Sure, but that's already currently the case for non-default precision. Besides, we made that package very minimal precisely to allow it to be referenced from anywhere.

[yykkibbb]

@AndriySvyryd Thank you for the feedback! @ErikEJ Thank you for the helpful discussion as well!

I've updated the approach to generate HasPrecision(precision, scale) instead of HasColumnType(...).

Changes:

• Renamed ShouldForceColumnType → ShouldAlwaysScaffoldPrecision in ScaffoldingTypeMapper
• When the hook returns true, precision/scale are always scaffolded even if they match defaults
• SqlServerScaffoldingTypeMapper overrides this for decimal

Updated behavior:

Case	Before	After
decimal(18,2)	Nothing scaffolded (runtime warning)	HasPrecision(18, 2)
decimal(14,3)	HasPrecision(14, 3)	HasPrecision(14, 3) (no change)
numeric(17,4)	HasColumnType("numeric(17,4)")	No change

[ErikEJ]

Not sure if EF Core supports money, but the same issue applies to that, I think

[yykkibbb]

@ErikEJ I checked the money / smallmoney case — they should not be affected by this issue.

Since their store type is "money" (or "smallmoney"), which doesn't match the default store type for decimal ("decimal(18,2)"), HasColumnType("money") is already scaffolded regardless of this change. So no runtime warning occurs for those types.

I've also added tests for both money and smallmoney to verify this behavior.