I have the following entities:
public interface IMyEntity
{
[Key]
int Id { get; set; }
IMyDetail MyDetail { get; set; }
ICollection
If you really need the abstraction offered by using interfaces then consider adding a domain layer to your application instead. The domain layer is meant to represent entities without the burden of persistence logic, which leads to a cleaner and more extensible architecture. (It's not clear that this is the OP's goal but it seems to be for other people who have discussed the same problem elsewhere.) This might be the only solution that doesn't introduce unintuitive constraints like the other solutions (explicit interface implementations, type casting problems...) If you go this route, you probably don't even need interfaces -- the domain class should be enough.
The end result could look like this in terms of the class/namespace structure:
namespace Domain.Entities // not EF
class MyDomainEntity
namespace DataAccess.Entities // EF entities
class MyDataAccessEntity // no relation to MyDomainEntity
namespace DataAccess.Entities.Mappers
class MyDataAccessEntityMapper // responsible for mapping MyDataAccessEntity to and from MyDomainEntity
This approach admittedly requires a lot more work. You will need 2 sets of entities (1 set for domain, 1 set for persistence) and classes to map between the domain and persistence entities. Therefore this approach is only worth it if there is a compelling reason. Otherwise, for small apps and apps whose persistence layer is not likely to change, there is likely less work and confusion if you keep using your EF entities.
However if you do go this route then you will see that working with domain (non-EF) entities in your app becomes easier, and keeping domain logic out of your EF entities makes the EF model easier to work with too.