[Custom Converter] SQLServer provider not recognizing properties of model when the clr type does not directly map to a DB type

[StevenRasmussen]

When using the new custom converters in 2.1, unless I first explicitly call .HasConversion on it, the properties are not considered to be a part of the 'EntityTypeBuilder' for the entity, and an error is thrown when trying to use the context.

Exception message: The property 'EFModel.End' could not be mapped, because it is of type 'Nullable<LocalTime>' which is not a supported primitive type or a valid entity type.

Steps to reproduce

See the following repo

1. Run the datamigration
2. Debug the console app
3. Error is thrown on line 17 of Program.cs

Further technical details

EF Core version: 2.1.0-preview1.final
Database Provider: Microsoft.EntityFrameworkCore.SqlServer
Operating system: Win10
IDE: Visual Studio 2017 15.6.4

[ajcvickers]

Note for triage: this is behaving as expected. The properties are not mapped until they have a converter that allows the provider to map them. We should consider this kind of scenario when implementing #9117. Also, filed #11589 to configure once for all properties of a type, since I couldn't find it on the backlog.

@SimplerSoftware The properties are not included in the model because they cannot be mapped by the database provider until there is a converter applied. So instead of using the model to try to discover properties, instead use Reflection on the CLR type to discover the properties that should have converters applied. These properties will then need to be added to the model with AddProperty before they can be configured with a converter.

[StevenRasmussen]

@ajcvickers Thanks for investigating and for the feedback. I’ll implement as you suggested. My only comment is that I would expect the InMemoryDb option to behave the same then. If you notice in my project everything works as I expected when using the InMemoryDb option but not when using the SQL server provider. Thanks!

[ajcvickers]

@SimplerSoftware It works for the in-memory database because it doesn't really do any mapping--it just saves the property values in memory. This means it is able to "map" almost any type, within the limitations that if the type is mutable and is mutated, then that will likely cause issues.