EnsureDeleted does not reset "identity" columns for InMemory database provider

When unit testing using the InMemory provider, we noticed that using the context.Database.EnsureDeleted() method does successfully “delete” the database (and its data), but it does not reset the values that are assigned to new records for integer id columns.

This is using 7.0.0-rc1-final.

Thanks, Kevin

Repro:

    public class Person
    {
        public int Id { get; set; }
        public string Name { get; set; }
    }

    public class MyContext : DbContext
    {
        public MyContext()
        {

        }

        public MyContext(DbContextOptions options) : base(options)
        {

        }

        public virtual DbSet<Person> People { get; set; }
    }

    [Fact]
    public void ShowFailure()
    {
        var db1 = GetMyDb();
        var zach1 = db1.People.Where(p => p.Id == 1).FirstOrDefault();
        Assert.NotNull(zach1); // works

        var db2 = GetMyDb();
        var zach2 = db2.People.Where(p => p.Id == 1).FirstOrDefault();
        Assert.NotNull(zach2); // fails (because the DB is on 3 and 4 now)
    }

    private static MyContext GetMyDb()
    {
        var optionsBuilder = new DbContextOptionsBuilder<MyContext>();

        // This is the magic line
        optionsBuilder.UseInMemoryDatabase();

        var db = new MyContext(optionsBuilder.Options);

        db.Database.EnsureDeleted();

        db.People.Add(
            new Person
            {
                Name = "Zach"
            });
        db.People.Add(
            new Person
            {
                Name = "George"
            }
        );

        db.SaveChanges();
        return db;
    }

[josh-sachs]

This complicates using InMemory provider for unit testing - which I thought was one of the major points of the provider in the first place.

1. If you mock the database with explicit keys, sequencing/auto-increment doesn’t happen at all. This breaks all unit tests that specifically test INSERT operations that expect keys to be generated.
2. If you delete a database, and then create a database, the implied behavior is that the newly created database would be unmolested by the previous one… It doesn’t matter what data store you are using… a new repository should always start with fresh seeds.

[ardalis]

I want to be able to test an ASPNET core mvc app using EF and inmemory. I’m finding that very difficult to do because of the fact there is no way to really reset an inmemory database. There is also no easy way I have found to provide a new service provider into a TestServer via its Startup class. I shouldn’t have to completely change how ASPNET core configures EF to do this, right? I had hopes that specifying a string to inmemory database would let me force it to use a new implementation, so for instance I tried using a new guid there, but that still didn’t work and the id values still stepped on one another.