Note: this currently removes annotations that are identified as by-convention by IAnnotationCodeGenerator from the context snapshopt - I'm guessing that's probably not good (since conventions may change across EF Core versions). If that's the case we should simply split IAnnotationCodeGenerator API - one for removing by-convention annotations, and another for generating fluent API calls.

Yes, we should do this. Otherwise it's looking good (though more elaborate than I imagined it)

We should also consider using IAnnotationCodeGenerator to remove the annotations that are never generated - #15675

+1 Looks good. Just need a way of generating by-convention annotations in the snapshot. Maybe a bool in HandleAnnotations()?

@bricelam

Just need a way of generating by-convention annotations in the snapshot. Maybe a bool in HandleAnnotations()?

I actually thought of just exposing two APIs - one which removes annotations which are by convention (called when scaffolding but not when generating the snapshot), and one which removes annotations for which a fluent API exists (and returns the fluent API calls).

@AndriySvyryd

Otherwise it's looking good (though more elaborate than I imagined it)

Did I over-engineer? Any ideas for simplifying?

should also consider using IAnnotationCodeGenerator to remove the annotations that are never generated

Will do this too.

Did I over-engineer? Any ideas for simplifying?

My initial design was just passing the string builder to the provider, but your way is better.

Superceded by #21329