EF Core 7.0'da (EF7) hataya neden olan değişiklikler

Bu sayfada, EF Core 6'dan EF Core 7'ye güncelleştirilen mevcut uygulamaların bozulmasına neden olabilecek API ve davranış değişiklikleri belgelenmiştir. EF Core'un önceki bir sürümünden güncelleştirme yapıyorsanız, önceki hataya neden olan değişiklikleri gözden geçirmeyi unutmayın:

• EF Core 6'da hataya neden olan değişiklikler

Hedef Çerçeve

EF Core 7.0, .NET 6'yi hedefler. Bu, .NET 6'yi hedefleyen mevcut uygulamaların bunu yapmaya devam edebilmesi anlamına gelir. Eski .NET, .NET Core ve .NET Framework sürümlerini hedefleyen uygulamaların EF Core 7.0 kullanmak için .NET 6 veya .NET 7'yi hedeflemesi gerekir.

Özet

Yüksek etkili değişiklikler

Encrypttrue SQL Server bağlantıları için varsayılan olarak

İzleme Sorunu: SqlClient #1210

Eski davranış

SqlClient bağlantı dizesi varsayılan olarak kullanılırEncrypt=False. Bu, yerel sunucunun geçerli bir sertifikaya sahip olmadığı geliştirme makinelerindeki bağlantılara izin verir.

Yeni davranış

SqlClient bağlantı dizesi varsayılan olarak kullanılırEncrypt=True. Bu şu anlama gelir:

• Sunucu geçerli bir sertifikayla yapılandırılmalıdır
• İstemcinin bu sertifikaya güvenmesi gerekir

Bu koşullar karşılanmazsa, bir SqlException oluşturulur. Örneğin:

Sunucuyla başarıyla bağlantı kuruldu ancak oturum açma işlemi sırasında bir hata oluştu. (sağlayıcı: SSL Sağlayıcısı, hata: 0 - Sertifika zinciri güvenilir olmayan bir yetkili tarafından verildi.)

Neden?

Bu değişiklik, varsayılan olarak bağlantının güvenli olduğundan veya uygulamanın bağlanamamasından emin olmak için yapılmıştır.

Risk Azaltıcı Etkenler

Devam etmenin üç yolu vardır:

1. Sunucuya geçerli bir sertifika yükleyin. Bunun ilgili bir işlem olduğunu ve bir sertifika almayı ve istemci tarafından güvenilen bir yetkili tarafından imzalandığından emin olmayı gerektirdiğini unutmayın.
2. Sunucunun bir sertifikası varsa, ancak istemci tarafından güvenilir değilse, TrustServerCertificate=True normal güven mekanizmasının atlanmasına izin vermek için.
3. açıkça bağlantı dizesi ekleyinEncrypt=False.

Bazı uyarılar varsayılan olarak yeniden özel durumlar oluşturur

İzleme Sorunu #29069

Eski davranış

EF Core 6.0'da SQL Server sağlayıcısındaki bir hata, varsayılan olarak özel durum oluşturmak üzere yapılandırılmış bazı uyarıların günlüğe kaydedildiğini ancak özel durumlar oluşturmadığını ifade etti. Bu uyarılar şunlardır:

Yeni davranış

EF Core 7.0'dan başlayarak, bu uyarılar varsayılan olarak yeniden bir özel durum oluşur.

Neden?

Bunlar, büyük olasılıkla uygulama kodunda düzeltilmesi gereken bir hatayı gösteren sorunlardır.

Risk Azaltıcı Etkenler

Uyarının nedeni olan temel sorunu düzeltin.

Alternatif olarak, uyarı düzeyi yalnızca günlüğe kaydedilecek veya tamamen gizlenecek şekilde değiştirilebilir. Örneğin:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    => optionsBuilder
        .ConfigureWarnings(b => b.Ignore(RelationalEventId.AmbientTransactionWarning));

Tetikleyicileri veya belirli hesaplanan sütunları olan SQL Server tabloları artık özel EF Core yapılandırması gerektiriyor

İzleme Sorunu #27372

Eski davranış

SQL Server sağlayıcısının önceki sürümleri değişiklikleri her zaman işe yarayan daha az verimli bir teknikle kaydetmiş.

Yeni davranış

Varsayılan olarak EF Core artık değişiklikleri önemli ölçüde daha verimli bir teknikle kaydeder; ne yazık ki, hedef tabloda veritabanı tetikleyicileri veya belirli türlerde hesaplanan sütun varsa bu teknik SQL Server'da desteklenmez. Diğer ayrıntılar için SQL Server belgelerine bakın.

Neden?

Yeni yönteme bağlı performans geliştirmeleri, bunları varsayılan olarak kullanıcılara getirmenin önemli olduğu kadar önemlidir. Aynı zamanda, EF Core uygulamalarında veritabanı tetikleyicilerinin veya etkilenen hesaplanan sütunların kullanımının, olumsuz hataya neden olan değişiklik sonuçlarının performans kazancından daha ağır basacak kadar düşük olacağını tahmin ediyoruz.

Risk Azaltıcı Etkenler

EF Core 8.0'dan başlayarak, "OUTPUT" yan tümcesinin kullanımı veya olmaması açıkça yapılandırılabilir. Örneğin:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Blog>()
        .ToTable(tb => tb.UseSqlOutputClause(false));
}

EF7 veya sonraki sürümlerde, hedef tablonun tetikleyicisi varsa EF Core'a bunu bildirebilirsiniz ve EF önceki, daha az verimli tekniğine geri döner. Bu, karşılık gelen varlık türü aşağıdaki gibi yapılandırılarak yapılabilir:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Blog>()
        .ToTable(tb => tb.HasTrigger("SomeTrigger"));
}

Bunu yapmak aslında EF Core'un tetikleyiciyi herhangi bir şekilde oluşturmasını veya yönetmesini sağlamaz. Şu anda yalnızca EF Core'a tetikleyicilerin tabloda mevcut olduğunu bildirir. Sonuç olarak, herhangi bir tetikleyici adı kullanılabilir. Tabloda aslında bir tetikleyici olmasa bile eski davranışı geri almak için bir tetikleyici belirtmek kullanılabilir.

Tablolarınızın çoğunun veya tümünün tetikleyicileri varsa, aşağıdaki model oluşturma kuralını kullanarak modelinizin tüm tabloları için daha yeni ve verimli tekniği kullanmayı geri çevirebilirsiniz:

public class BlankTriggerAddingConvention : IModelFinalizingConvention
{
    public virtual void ProcessModelFinalizing(
        IConventionModelBuilder modelBuilder,
        IConventionContext<IConventionModelBuilder> context)
    {
        foreach (var entityType in modelBuilder.Metadata.GetEntityTypes())
        {
            var table = StoreObjectIdentifier.Create(entityType, StoreObjectType.Table);
            if (table != null
                && entityType.GetDeclaredTriggers().All(t => t.GetDatabaseName(table.Value) == null)
                && (entityType.BaseType == null
                    || entityType.GetMappingStrategy() != RelationalAnnotationNames.TphMappingStrategy))
            {
                entityType.Builder.HasTrigger(table.Value.Name + "_Trigger");
            }

            foreach (var fragment in entityType.GetMappingFragments(StoreObjectType.Table))
            {
                if (entityType.GetDeclaredTriggers().All(t => t.GetDatabaseName(fragment.StoreObject) == null))
                {
                    entityType.Builder.HasTrigger(fragment.StoreObject.Name + "_Trigger");
                }
            }
        }
    }
}

kuralınızı DbContext geçersiz kılarak ConfigureConventionskullanın:

protected override void ConfigureConventions(ModelConfigurationBuilder configurationBuilder)
{
    configurationBuilder.Conventions.Add(_ => new BlankTriggerAddingConvention());
}

Bu, her tablo için el ile yapmak zorunda kalmak yerine modelinizin tüm tablolarını etkili bir şekilde çağırır HasTrigger .

AFTER tetikleyicileri ve sanal tablolar içeren SQLite tabloları artık özel EF Core yapılandırması gerektiriyor

İzleme Sorunu #29916

Eski davranış

SQLite sağlayıcısının önceki sürümleri değişiklikleri her zaman işe yarayan daha az verimli bir teknikle kaydetmiş.

Yeni davranış

Varsayılan olarak, EF Core artık RETURNING yan tümcesini kullanarak değişiklikleri daha verimli bir teknikle kaydeder. Ne yazık ki, hedef tabloda VERITABANı AFTER tetikleyicileri varsa, sanalsa veya SQLite'in eski sürümleri kullanılıyorsa bu teknik SQLite'te desteklenmez. Daha fazla ayrıntı için SQLite belgelerine bakın.

Neden?

Yeni yönteme bağlı basitleştirmeler ve performans geliştirmeleri, bunları varsayılan olarak kullanıcılara getirmenin önemli olduğu kadar önemlidir. Aynı zamanda, EF Core uygulamalarında veritabanı tetikleyicilerinin ve sanal tabloların kullanımının, olumsuz hataya neden olan değişiklik sonuçlarının performans artışından daha ağır basacağı kadar düşük olacağını tahmin ediyoruz.

Risk Azaltıcı Etkenler

EF Core 8.0'da yöntemi, UseSqlReturningClause daha eski, daha az verimli SQL'e açıkça geri dönmek için kullanıma sunulmuştur. Örneğin:

protected override void OnModelCreating(ModelBuilder modelBuilder)
{
    modelBuilder.Entity<Blog>()
        .ToTable(tb => tb.UseSqlReturningClause(false));
}

EF Core 7.0 kullanmaya devam ediyorsanız bağlam yapılandırmanıza aşağıdaki kodu ekleyerek uygulamanın tamamı için eski mekanizmaya geri dönebilirsiniz:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    => optionsBuilder
        .UseSqlite(...)
        .ReplaceService<IUpdateSqlGenerator, SqliteLegacyUpdateSqlGenerator>();

Orta düzeyde etki eden değişiklikler

İsteğe bağlı ilişkilerin yalnız bırakılmış bağımlıları otomatik olarak silinmez

İzleme Sorunu #27217

Eski davranış

Yabancı anahtarı null atanabilirse ilişki isteğe bağlıdır . Yabancı anahtarı null olarak ayarlamak, bağımlı varlığın ilgili asıl varlık olmadan var olmasını sağlar. İsteğe bağlı ilişkiler, varsayılan olmasa da art arda silmeleri kullanacak şekilde yapılandırılabilir.

İsteğe bağlı bir bağımlı, yabancı anahtarı null olarak ayarlanarak veya bu anahtara veya bu anahtardan gezinti temizlenerek sorumlusundan kesilebilir. EF Core 6.0'da bu, ilişki art arda silme için yapılandırıldığında bağımlının silinmesine neden olabilir.

Yeni davranış

EF Core 7.0'dan itibaren bağımlı artık silinmez. Sorumlu silinirse, art arda silmeler ilişki için yapılandırıldığından bağımlının yine de silineceğini unutmayın.

Neden?

Bağımlı, bir sorumluyla herhangi bir ilişki olmadan var olabilir, bu nedenle ilişkinin kesilmesi varlığın silinmesine neden olmamalıdır.

Risk Azaltıcı Etkenler

Bağımlı açıkça silinebilir:

context.Remove(blog);

Alternatif SaveChanges olarak, asıl başvuru olmadan bağımlıları silmek için geçersiz kılınabilir veya kesilebilir. Örneğin:

context.SavingChanges += (c, _) =>
    {
        foreach (var entry in ((DbContext)c!).ChangeTracker
            .Entries<Blog>()
            .Where(e => e.State == EntityState.Modified))
        {
            if (entry.Reference(e => e.Author).CurrentValue == null)
            {
                entry.State = EntityState.Deleted;
            }
        }
    };

SQL Server ile TPT eşlemesi kullanılırken tablolar arasında art arda silme yapılandırılır

İzleme Sorunu #28532

Eski davranış

TPT stratejisini kullanarak bir devralma hiyerarşisini eşlerken, temel tablo o varlığın gerçek türüne bakılmaksızın kaydedilen her varlık için bir satır içermelidir. Temel tablodaki satır silindiğinde diğer tüm tablolardaki satırlar silinmelidir. EF Core bunun için art arda silmeleri yapılandırıyor .

EF Core 6.0'da SQL Server veritabanı sağlayıcısındaki bir hata, bu art arda silmelerin oluşturulmadığı anlamına geliyordu.

Yeni davranış

EF Core 7.0'dan başlayarak sql server için art arda silme işlemleri her zaman diğer veritabanları için olduğu gibi oluşturulur.

Neden?

Temel tablodan TPT'deki alt tablolara art arda silme işlemleri, bir varlığın temel tablodaki satırını silerek silinmesini sağlar.

Risk Azaltıcı Etkenler

Çoğu durumda, bu değişiklik herhangi bir soruna neden olmamalıdır. Ancak, tablolar arasında yapılandırılmış birden çok art arda davranış olduğunda SQL Server çok kısıtlayıcıdır. Bu, TPT eşlemesindeki tablolar arasında var olan bir basamaklı ilişki varsa SQL Server'ın aşağıdaki hatayı oluşturabileceği anlamına gelir:

Microsoft.Data.SqlClient.SqlException: DELETE deyimi "FK_Blogs_People_OwnerId" BAŞVURU kısıtlamasıyla çakıştı. Çakışma "Scratch" adlı "dbo" tablosunda oluştu. Bloglar", 'OwnerId' sütunu. Deyim sonlandırıldı.

Örneğin, bu model basamaklı ilişkiler döngüsü oluşturur:

[Table("FeaturedPosts")]
public class FeaturedPost : Post
{
    public int ReferencePostId { get; set; }
    public Post ReferencePost { get; set; } = null!;
}

[Table("Posts")]
public class Post
{
    public int Id { get; set; }
    public string? Title { get; set; }
    public string? Content { get; set; }
}

Bunlardan birinin sunucuda art arda silmeleri kullanmayacak şekilde yapılandırılması gerekir. Örneğin, açık ilişkiyi değiştirmek için:

modelBuilder
    .Entity<FeaturedPost>()
    .HasOne(e => e.ReferencePost)
    .WithMany()
    .OnDelete(DeleteBehavior.ClientCascade);

Veya TPT eşlemesi için oluşturulan örtük ilişkiyi değiştirmek için:

modelBuilder
    .Entity<FeaturedPost>()
    .HasOne<Post>()
    .WithOne()
    .HasForeignKey<FeaturedPost>(e => e.Id)
    .OnDelete(DeleteBehavior.ClientCascade);

Önceden yazma günlüğü kullanmazken SQLite'te meşgul/kilitli hata olasılığı daha yüksek

Eski davranış

SQLite sağlayıcısının önceki sürümleri, tablo kilitli/meşgul olduğunda ve önceden yazma günlüğü (WAL) etkinleştirilmediğinde otomatik olarak yeniden deneyebilen daha az verimli bir teknikle değişiklikleri kaydetmişti.

Yeni davranış

Varsayılan olarak, EF Core artık RETURNING yan tümcesini kullanarak değişiklikleri daha verimli bir teknikle kaydeder. Ne yazık ki, bu teknik meşgul/kilitli olduğunda otomatik olarak yeniden denenemez. Önceden yazma günlüğü kullanmayan çok iş parçacıklı bir uygulamada (web uygulaması gibi) bu hatalarla karşılaşmak yaygın bir durumdur.

Neden?

Yeni yönteme bağlı basitleştirmeler ve performans geliştirmeleri, bunları varsayılan olarak kullanıcılara getirmenin önemli olduğu kadar önemlidir. EF Core tarafından oluşturulan veritabanları, varsayılan olarak önceden yazma günlüğünü de etkinleştirir. SQLite ekibi, önceden yazma günlüğünün varsayılan olarak etkinleştirilmesini de önerir.

Risk Azaltıcı Etkenler

Mümkünse, veritabanınızda önceden yazma günlüğünü etkinleştirmeniz gerekir. Veritabanınız EF tarafından oluşturulduysa, bu durum zaten geçerli olmalıdır. Aksi takdirde, aşağıdaki komutu yürüterek önceden yazma günlüğünü etkinleştirebilirsiniz.

PRAGMA journal_mode = 'wal';

Bir nedenle önceden yazma günlüğünü etkinleştiremiyorsanız bağlam yapılandırmanıza aşağıdaki kodu ekleyerek uygulamanın tamamı için eski mekanizmaya geri dönebilirsiniz:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    => optionsBuilder
        .UseSqlite(...)
        .ReplaceService<IUpdateSqlGenerator, SqliteLegacyUpdateSqlGenerator>();

protected override void ConfigureConventions(ModelConfigurationBuilder configurationBuilder)
{
    configurationBuilder.Conventions.Add(_ => new DoNotUseReturningClauseConvention());
}

class DoNotUseReturningClauseConvention : IModelFinalizingConvention
{
    public void ProcessModelFinalizing(
        IConventionModelBuilder modelBuilder,
        IConventionContext<IConventionModelBuilder> context)
    {
        foreach (var entityType in modelBuilder.Metadata.GetEntityTypes())
        {
            entityType.UseSqlReturningClause(false);
        }
    }
}

Düşük etkili değişiklikler

Anahtar özelliklerin bir sağlayıcı değer karşılaştırıcısıyla yapılandırılması gerekebilir

İzleme Sorunu #27738

Eski davranış

EF Core 6.0'da, değişiklikleri kaydederken anahtar değerlerini karşılaştırmak için doğrudan varlık türlerinin özelliklerinden alınan anahtar değerleri kullanıldı. Bu, bu özelliklerde yapılandırılan tüm özel değer karşılaştırıcılarını kullanır.

Yeni davranış

EF Core 7.0'dan başlayarak, bu karşılaştırmalar için veritabanı değerleri kullanılır. Bu ,vakaların büyük çoğunluğu için "sadece işe yarar". Ancak, özellikler özel bir karşılaştırıcı kullanıyorsa ve bu karşılaştırıcı veritabanı değerlerine uygulanamıyorsa, aşağıda gösterildiği gibi bir "sağlayıcı değer karşılaştırıcısı" gerekebilir.

Neden?

Çeşitli varlık bölme ve tablo bölme, aynı veritabanı sütununa eşlenmiş birden çok özelliğe neden olabilir ve bunun tersi de geçerlidir. Bunun için, veritabanında kullanılacak değere dönüştürme işleminden sonra değerlerin karşılaştırılması gerekir.

Risk Azaltıcı Etkenler

Sağlayıcı değeri karşılaştırıcısı yapılandırın. Örneğin, bir değer nesnesinin anahtar olarak kullanıldığı durumu ve bu anahtarın karşılaştırıcısının büyük/küçük harfe duyarlı olmayan dize karşılaştırmalarını kullandığını düşünün:

var blogKeyComparer = new ValueComparer<BlogKey>(
    (l, r) => string.Equals(l.Id, r.Id, StringComparison.OrdinalIgnoreCase),
    v => v.Id.ToUpper().GetHashCode(),
    v => v);

var blogKeyConverter = new ValueConverter<BlogKey, string>(
    v => v.Id,
    v => new BlogKey(v));

modelBuilder.Entity<Blog>()
    .Property(e => e.Id).HasConversion(
        blogKeyConverter, blogKeyComparer);

Veritabanı değerleri (dizeler), türler için BlogKey tanımlanan karşılaştırıcıyı doğrudan kullanamaz. Bu nedenle, büyük/küçük harfe duyarlı olmayan dize karşılaştırmaları için bir sağlayıcı karşılaştırıcısı yapılandırılmalıdır:

var caseInsensitiveComparer = new ValueComparer<string>(
    (l, r) => string.Equals(l, r, StringComparison.OrdinalIgnoreCase),
    v => v.ToUpper().GetHashCode(),
    v => v);

var blogKeyComparer = new ValueComparer<BlogKey>(
    (l, r) => string.Equals(l.Id, r.Id, StringComparison.OrdinalIgnoreCase),
    v => v.Id.ToUpper().GetHashCode(),
    v => v);

var blogKeyConverter = new ValueConverter<BlogKey, string>(
    v => v.Id,
    v => new BlogKey(v));

modelBuilder.Entity<Blog>()
    .Property(e => e.Id).HasConversion(
        blogKeyConverter, blogKeyComparer, caseInsensitiveComparer);

Denetim kısıtlamaları ve diğer tablo modelleri artık tabloda yapılandırıldı

İzleme Sorunu #28205

Eski davranış

EF Core 6.0'da , HasCheckConstraintHasCommentve IsMemoryOptimized doğrudan varlık türü oluşturucusunda çağrıldı. Örneğin:

modelBuilder
    .Entity<Blog>()
    .HasCheckConstraint("CK_Blog_TooFewBits", "Id > 1023");

modelBuilder
    .Entity<Blog>()
    .HasComment("It's my table, and I'll delete it if I want to.");

modelBuilder
    .Entity<Blog>()
    .IsMemoryOptimized();

Yeni davranış

EF Core 7.0'dan başlayarak, bu yöntemler bunun yerine tablo oluşturucuda çağrılır:

modelBuilder
    .Entity<Blog>()
    .ToTable(b => b.HasCheckConstraint("CK_Blog_TooFewBits", "Id > 1023"));

modelBuilder
    .Entity<Blog>()
    .ToTable(b => b.HasComment("It's my table, and I'll delete it if I want to."));

modelBuilder
    .Entity<Blog>()
    .ToTable(b => b.IsMemoryOptimized());

Mevcut yöntemler olarak Obsoleteişaretlendi. Şu anda yeni yöntemlerle aynı davranışa sahipler, ancak gelecek bir sürümde kaldırılacaklar.

Neden?

Bu modeller yalnızca tablolara uygulanır. Bunlar eşlenen görünümlere, işlevlere veya saklı yordamlara uygulanmaz.

Risk Azaltıcı Etkenler

Yukarıda gösterildiği gibi tablo oluşturucu yöntemlerini kullanın.

Yeni varlıklardan silinen varlıklara gezintiler düzeltilmedi

İzleme Sorunu #28249

Eski davranış

EF Core 6.0'da, yeni bir varlık bir izleme sorgusundan veya öğesine eklenerek DbContextizlendiğinde, durumdaki ilgili varlıklara ve varlıklardan Deleted gezintiler düzeltilir.

Yeni davranış

EF Core 7.0'dan başlayarak varlıklara ve varlıklardan Deleted gezintiler düzeltilmemiştir.

Neden?

Varlık, silinmemiş varlıklarla ilişkilendirildiği için nadiren işaretlendikten Deleted sonra anlamlı olur.

Risk Azaltıcı Etkenler

Varlıkları olarak Deletedişaretlemeden önce varlıkları sorgulayıp ekleyin ya da silinen varlığa ve bu varlıktan gezinti özelliklerini el ile ayarlayın.

FromSqlRaw Yanlış sağlayıcıdan ve ilgili yöntemlerin kullanılması use-the-correct-metoduna neden oluyor

İzleme Sorunu #26502

Eski davranış

EF Core 6.0'da, ilişkisel sağlayıcı kullanırken Azure Cosmos DB FromSqlRaw uzantısı yönteminin kullanılması veya Azure Cosmos DB sağlayıcısını kullanırken ilişkisel FromSqlRaw uzantı yönteminin kullanılması sessizce başarısız olabilir. Benzer şekilde, bellek içi sağlayıcıda ilişkisel yöntemlerin kullanılması sessiz bir işlem yapılmaz.

Yeni davranış

EF Core 7.0'dan başlayarak, farklı bir sağlayıcıda bir sağlayıcı için tasarlanmış bir uzantı yöntemi kullanıldığında özel durum oluşturulur.

Neden?

Her durumda düzgün çalışması için doğru uzantı yöntemi kullanılmalıdır.

Risk Azaltıcı Etkenler

Kullanılan sağlayıcı için doğru uzantı yöntemini kullanın. Birden çok sağlayıcıya başvurulursa, uzantı yöntemini statik yöntem olarak çağırın. Örneğin:

var result = CosmosQueryableExtensions.FromSqlRaw(context.Blogs, "SELECT ...").ToList();

Veya:

var result = RelationalQueryableExtensions.FromSqlRaw(context.Blogs, "SELECT ...").ToList();

yapı iskelesi artık çağrılmadı OnConfiguringIsConfigured

İzleme Sorunu #4274

Eski davranış

EF Core 6.0'da, DbContext var olan bir veritabanından iskelesi oluşturulmuş tür için IsConfiguredbir çağrı içeriyordu. Örneğin:

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
    if (!optionsBuilder.IsConfigured)
    {
#warning To protect potentially sensitive information in your connection string, you should move it out of source code. You can avoid scaffolding the connection string by using the Name= syntax to read it from configuration - see https://go.microsoft.com/fwlink/?linkid=2131148. For more guidance on storing connection strings, see http://go.microsoft.com/fwlink/?LinkId=723263.
        optionsBuilder.UseNpgsql("MySecretConnectionString");
    }
}

Yeni davranış

EF Core 7.0'dan itibaren çağrısı IsConfigured artık dahil değildir.

Neden?

Veritabanı sağlayıcısının bazı durumlarda DbContext içinde yapılandırıldığı ancak bağlamın henüz yapılandırılmadığı çok sınırlı senaryolar vardır. Bunun yerine, buradan ayrılarak OnConfiguring derleme zamanı uyarısına rağmen kodda hassas bilgiler içeren bir bağlantı dizesi bırakılması daha olasıdır. Bu nedenle, özellikle (.NET CLI) veya -NoOnConfiguring (Visual Studio Paket Yöneticisi Konsolu) bayrağının yöntemin --no-onconfiguring iskelesini önlemek için kullanılabilmesi ve gerçekten gerekliyse geri IsConfigured eklemek için özelleştirilebilir şablonların OnConfiguring mevcut olması durumunda, bunu kaldırmaya yönelik ek güvenli ve temiz kod faydalı olarak kabul edildi.

Risk Azaltıcı Etkenler

Şunlardan biri:

• Var olan bir veritabanından yapı iskelesi --no-onconfiguring oluştururken (.NET CLI) veya -NoOnConfiguring (Visual Studio Paket Yöneticisi Konsolu) bağımsız değişkenini kullanın.
• çağrısına IsConfiguredgeri eklemek için T4 şablonlarını özelleştirin.