DatabaseGeneratedOption.None Not Honored on ID Field When Published to Azure

[markolbert]

This is under EF Core 1.0.

I have a simple class, County, whose integer ID is an input element, not auto-incremented:

    public class County
    {
        [DatabaseGenerated(DatabaseGeneratedOption.None)]
        public int ID { get; set; }

        [Required]
        [StringLength(100)]
        public string Name { get; set; }

        [Required]
        [DefaultValue(false)]
        public bool CombinedVoterBallotFile { get; set; }

        public ICollection<Voter> Voters { get; set; }
        public ICollection<City> Cities { get; set; }
        public ICollection<CountyAgency> CountyAgencies { get; set; }
    }

When I use dotnet ef migrations add & dotnet ef database update locally, this correctly sets the ID field as non-nullable integer, but not an identity field (in SqlServer 2016).

However, when I published this app to Azure, the migration process ended up creating the field as non-nullable integer, but also as an identity field. This naturally caused problems when I tried to assign a value to the ID field when creating and saving a new instance of County.

As I am new to Azure I'm not sure this isn't something I caused myself, owing to how the migration was done. Basically, all I did, in a database seeding class I wrote, was to call:

_context.Database.Migrate();
And the entire database appeared to be built like magic, without me taking any other steps. Except that the ID field was defined wrong (it's the only DatabaseGeneratedOption.None field in my schema).

For fun, I tried using fluid design to reinforce the correct nature of that ID field (I left the annotation on the ID field while adding this next line to the OnModelCreating() method in the database context class):

builder.Entity<County>().Property( c => c.ID ).ValueGeneratedNever();
While this worked fine locally -- a new migration was created, and the local database was "updated" without any problems -- it did not solve the problem in the Azure database. To fix that, I had to go in via SSMS and manually edit the definition for the ID field. Not a big deal, but kind of annoying.

• Mark

[markolbert]

This problem isn't limited to publishing to Azure. I just recreated the database, via migrations within VS 2015, on my tablet and the same problem appeared.

[divega]

@markolbert could you provide a project (e.g. a console app) that repros this issue?

[markolbert]

Here you go. When I execute dotnet ef database update, the database (testdb) is created, all the migrations are successfully applied, and the ID field in County is an identity field, when it shouldn't be.
ConsoleAppNonGeneratedID.zip

Let me know if you need any more information.

[ajcvickers]

@markolbert I believe you are hitting this issue: #5345. Specifically, once a column has been created as an Identity column it is not possible to change that without rebuilding the table. Rebuilding the table is not something that Migrations can handle currently. In the current release the result is that a change to Identity is just ignored. In 1.1 Migrations will let you know that Migrations cannot handle the change--that is what #5345 was about.

[markolbert]

Ah! Yes, when I first defined the County table ID was autogenerated. I don't recall having to change that manually in the development database when I switched it to value-provided, but I must've forgotten.

What I'm still confused by, though, is why it was a problem when the Azure database was created. Do the migrations get applied sequentially to the database, or are they "merged" together into one setup? I guess I assumed it was the latter, but it sounds like it's done sequentially. Which would definitely recreate the problem I ran into.

[ajcvickers]

@markolbert The migrations are applied sequentially.

[markolbert]

Good to know, thanx. I'll close this issue.