Allow specifying value converter instance in ConfigureConventions

[andriysavin]

In ConfigureConventions I can specify a converter for all properties of certain type. But unlike with "regular" converter configuring, here I can only specify converter type, but not instance:

protected override void ConfigureConventions(ModelConfigurationBuilder configurationBuilder)
{
    configurationBuilder
        .Properties<Currency>()
        .HaveConversion<CurrencyConverter>();
}

This limits only to converters which have parameterless constructors. But in some cases it's useful to be able to pass some additional information to particular converter usage.

For instance, I have a converter which converts a DateTimeOffset to DateTime in specified time zone. Converter's constructor has this look:

public DateTimeOffsetToDateTimeConverter(TimeZoneInfo timeZone)

To configure properties with this converter with a specific time zone I have to derive new type which hardcodes this time zone, so it has parameterless contructor and specifying just type is enough. But even this trick will not work if you need to decide on parameter value at run time.

[ajcvickers]

@AndriySvyryd Isn't this by-design so that it is always compatible with compiled models?

[AndriySvyryd]

It is, but we could allow it if there are enough users who need it and don't use compiled models.
Alternatively, we could allow the specified converter type to be resolved from DI if it doesn't have a parameterless constructor

[Cubelaster]

DI resolution would be awesome.
Something like TypeFilterAttribute or ServiceFilter?

Although, @andriysavin I would recommend storing all Date properties as UTC in database and handling the display on client.
It will make your life easier because DateTimeOffset changes during year...
If I understood what you're trying to do?

[andriysavin]

@Cubelaster sorry for delayed response. Unfortunately, in my case the DB historically stores date/time in particular time zone, and there is no desire to migrate the data (and the code which is bound to this approach). I won't be surprised if I'm not alone with such problem.
Instantiating converter via DI would be a bit overkill for my particular case, but in general a pretty viable solution.

[QuantumToasted]

Would appreciate being able to pass an instance or resolve constructor parameters from DI as well!
I have a custom type which needs to resolve the converted DB string to a class via a service method - this service only has these methods available at runtime after startup as it needs to "cache" information - and I need some way to be able to convert my type from the string stored in the DB.

I currently have an extension method which simply loops through all columns in all tables in OnModelCreating and assigns them a value converter instance, but I just learned about HaveConversion() which effectively accomplishes the exact same thing....minus this feature.

[ajcvickers]

@QuantumToasted Implementing this would not help your case, since it would require a new model to be built every time a different converter is used. #12205 would be more appropriate for this.