ModelBuilder: Shadow property introduction doesn't work without calling Property<T>()

[bricelam]

class TestClass
{
    public string Name { get; set; }
}

class Test
{
    public int Id { get; set; }
    public TestClass Class { get; set; }
}

modelBuilder.Entity<TestClass>(
    x =>
    {
        // NOTE: HasKey fails without this
        x.Property<string>("AssemblyName");

        x.HasKey("AssemblyName", "Name");
    });
modelBuilder.Entity<Test>(
    x =>
    {
        // NOTE: HasForeignKey fails without this
        x.Property<string>("AssemblyName");

        x.HasOne(t => t.Class).WithMany(c => c.Tests)
            .HasForeignKey("AssemblyName", "ClassName");
    });

[smitpatel]

HasKey does not create shadow properties therefore the shadow property needs to be defined first. (same with HasIndex)
HasForeignKey creates shadow properties but only when there is compatible Principal Key to replicate the property types. For composite FK, there should be either HasPrincipalKey call or principal type should have composite PK defined.
At present we only replicate the type if the referenced property is non-shadow.

[divega]

Updating title because the issue isn't specific to composite keys.

It would be nice if calling HasKey("Id") could act as a shortcut to both create the property (if it didn't already exists) and to make it a key, but HasKey() currently doesn't provide a way to specify the type.

BTW, the exception is:

The property 'Id' cannot be added to the entity type 'Customer' because there was no property type specified and there is no corresponding CLR property. To add a shadow state property the property type needs to be specified.

[smitpatel]

One of the reasons for not creating shadow properties for HasKey & HasIndex is "typo"

[divega]

@smitpatel agreed, but when using the string version of Property<T>() we already assume the user's intent is a bit more likely to be to refer to a shadow property. Then by extension I think it would be ok to assume the same thing for other string based APIs on the same EntityTypeBuilder where the property would need to be created.

In any case (unless I am missing a detail that justified the original title to be about composite keys), this is assigned to 1.0.1, so we can discuss it soon.