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:
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
Encrypt
true
SQL Server bağlantıları için varsayılan olarak
İzleme Sorunu: SqlClient #1210
Önemli
Bu, Microsoft.Data.SqlClient paketinde önemli bir hataya neden olan değişikliktir. EF Core'da bu değişikliği geri döndürmek veya azaltmak için yapılabilecek hiçbir şey yoktur. Lütfen Microsoft.Data.SqlClient GitHub Deposu'na geri bildirim gönderin veya ek sorular veya yardım için bir Microsoft Desteği Professional ile iletişime geçin.
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:
- 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.
- Sunucunun bir sertifikası varsa, ancak istemci tarafından güvenilir değilse,
TrustServerCertificate=True
normal güven mekanlarının atlanmasına izin vermek için. - açıkça bağlantı dizesi ekleyin
Encrypt=False
.
Uyarı
Hem 2 hem de 3 seçenekleri sunucuyu güvenli olmayabilecek bir durumda bırakır.
Bazı uyarılar varsayılan olarak yeniden özel durumlar oluşturur
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:
EventId | Açıklama |
---|---|
RelationalEventId.AmbientTransactionWarning | Bir uygulama, gerçekten yoksayıldığında bir ortam işleminin kullanılmasını beklemiş olabilir. |
RelationalEventId.IndexPropertiesBothMappedAndNotMappedToTable | Dizin, bazıları eşlenen, bazıları tablodaki bir sütuna eşlenmeyen özellikleri belirtir. |
RelationalEventId.IndexPropertiesMappedToNonOverlappingTables | Dizin, örtüşmeyen tablolardaki sütunlara eşlenen özellikleri belirtir. |
RelationalEventId.ForeignKeyPropertiesMappedToUnrelatedTables | Yabancı anahtar, ilgili tablolarla eşleşmeyen özellikleri belirtir. |
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
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 ConfigureConventions
kullanı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
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
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
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_Kişiler_OwnerId" REFERENCE 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>();
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
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ı
Eski davranış
EF Core 6.0'da , HasCheckConstraint
HasComment
ve 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 Obsolete
iş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
Eski davranış
EF Core 6.0'da, yeni bir varlık bir izleme sorgusundan veya öğesine eklenerekDbContext
izlendiğ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 Deleted
iş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
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ı OnConfiguring
IsConfigured
Eski davranış
EF Core 6.0'da, DbContext
var olan bir veritabanından iskelesi oluşturulmuş tür için IsConfigured
bir ç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
IsConfigured
geri eklemek için T4 şablonlarını özelleştirin.