Guid Keys don't appear to generate migrations as expected

[TehWardy]

GIVEN
That I create a new Entity in a new model and add an entity Type as a DbSet to my context.
That this Entity type has the following primary key definition ...

[Key]
[DatabaseGenerated(DatabaseGeneratedOption.Identity)]
public Guid Id { get; set; }

WHEN
I enable migrations, and foll up with "add-migration Initial" in the PMC window.

THEN
I would expect to see in that initial migration ...

CreateTable(
    "dbo.TableName",
    c => new
        {
            Id = c.Guid(nullable: false, identity: true, defaultValueSql: "newid()"),
             ...

...

The assertion here fails as the generated migration code looks like ...

CreateTable(
    "dbo.TableName",
    c => new
        {
            Id = c.Guid(nullable: false, identity: true),
             ...

How can I specify this in the database generated / key attributes / fluent API to force this behaviour?

[TehWardy]

Given that there are many "options" to this might i suggest supporting something like this ..

[Key]
[DatabaseGenerated(DatabaseGeneratedOption.Identity, defaultSql: "newid()")]
public Guid Id { get; set; }

... this would also allow the id generation to be overridden where it's declared, with that value being the default if it's not specified anyway.
Obviously this would only apply to Guid Keys, with for example string keys the value would have to be manually computed perhaps with a custom sql function.

[TehWardy]

Further details on the issue ...
https://stackoverflow.com/questions/50930786/ef-code-first-migrations-db-generated-guid-keys

It seems that for the same property code on different types EF generates different migration code.
Making this consistent is part of the issue but it would be best if "DatabaseGeneratedOption.Identity" really meant that when applied to a [key] property instead of "sometimes means that if you go and alter the migration code or add model builder script lines".

[ajcvickers]

EF Team Triage: This issue is not something that our team is planning to address in the EF6.x code base. This does not mean that we would not consider a community contribution to address this issue.

Moving forwards, our team will be fixing bugs, implementing small improvements, and accepting community contributions to the EF6.x code base. Larger feature work and innovation will happen in the EF Core code base (https://github.com/aspnet/EntityFramework).

Closing an issue in the EF6.x project does not exclude us addressing it in EF Core. In fact, a number of popular feature requests for EF have already been implemented in EF Core (alternate keys, batching in SaveChanges, etc.).

BTW this is a canned response and may have info or details that do not directly apply to this particular issue. While we'd like to spend the time to uniquely address every incoming issue, we get a lot traffic on the EF projects and that is not practical. To ensure we maximize the time we have to work on fixing bugs, implementing new features, etc. we use canned responses for common triage decisions.