From 8e6c79f726a524a5daf6dcb9dc687f102bde9cdf Mon Sep 17 00:00:00 2001
From: Shay Rojansky <roji@roji.org>
Date: Wed, 1 Oct 2025 19:15:23 +0200
Subject: [PATCH] Release note updates for 10.0.0-rc.2

And add security section
---
 .../extensions-logging.md                     | 14 ----
 .../core/what-is-new/ef-core-10.0/whatsnew.md | 75 +++++++++++++++++--
 .../core/what-is-new/ef-core-8.0/whatsnew.md  |  2 +-
 .../core/what-is-new/ef-core-9.0/whatsnew.md  |  2 +-
 4 files changed, 69 insertions(+), 24 deletions(-)

diff --git a/entity-framework/core/logging-events-diagnostics/extensions-logging.md b/entity-framework/core/logging-events-diagnostics/extensions-logging.md
index 86cbb334a7..c18ebea30a 100644
--- a/entity-framework/core/logging-events-diagnostics/extensions-logging.md
+++ b/entity-framework/core/logging-events-diagnostics/extensions-logging.md
@@ -24,26 +24,12 @@ Other application types can use the [GenericHost](/dotnet/core/extensions/generi
 
 `Microsoft.Extensions.Logging` requires creation of a <xref:Microsoft.Extensions.Logging.LoggerFactory>. This factory should be stored as a static/global instance somewhere and used each time a DbContext is created. For example, it is common to store the logger factory as a static property on the DbContext.
 
-### [EF Core 3.0 and above](#tab/v3)
-
 <!--
         public static readonly ILoggerFactory MyLoggerFactory
             = LoggerFactory.Create(builder => { builder.AddConsole(); });
 -->
 [!code-csharp[Main](../../../samples/core/Miscellaneous/Logging/Logging/BloggingContext.cs#DefineLoggerFactory)]
 
-### [EF Core 2.1](#tab/v2)
-
-```csharp
-public static readonly LoggerFactory MyLoggerFactory
-    = new LoggerFactory(new[] { new ConsoleLoggerProvider((_, __) => true, true) });
-```
-
-> [!WARNING]
-> In EF Core 2.1, It is very important that applications do not create a new LoggerFactory instance for each DbContext instance. Doing so will result in a memory leak and poor performance. This has been fixed in EF Core 3.0 and above.
-
-***
-
 This singleton/global instance should then be registered with EF Core on the <xref:Microsoft.EntityFrameworkCore.DbContextOptionsBuilder>. For example:
 
 <!--
diff --git a/entity-framework/core/what-is-new/ef-core-10.0/whatsnew.md b/entity-framework/core/what-is-new/ef-core-10.0/whatsnew.md
index 5b84bddb7d..79ee086e4d 100644
--- a/entity-framework/core/what-is-new/ef-core-10.0/whatsnew.md
+++ b/entity-framework/core/what-is-new/ef-core-10.0/whatsnew.md
@@ -1,8 +1,8 @@
 ---
 title: What's New in EF Core 10
 description: Overview of new features in EF Core 10
-author: maumar
-ms.date: 01/05/2025
+author: roji
+ms.date: 10/02/2025
 uid: core/what-is-new/ef-core-10.0/whatsnew
 ---
 
@@ -10,13 +10,15 @@ uid: core/what-is-new/ef-core-10.0/whatsnew
 
 EF Core 10 (EF10) is the next release after EF Core 9 and is scheduled for release in November 2025.
 
-EF10 is available as a preview. See [.NET 10 release notes](https://github.com/dotnet/core/tree/main/release-notes/10.0) to get information about the latest preview. This article will be updated as new preview releases are made available.
+EF10 is available as a preview. [See the .NET 10 release notes](https://github.com/dotnet/core/tree/main/release-notes/10.0) to get information about the latest .NET preview.
 
 > [!TIP]
 > You can run and debug into the samples by [downloading the sample code from GitHub](https://github.com/dotnet/EntityFramework.Docs). Each section below links to the source code specific to that section.
 
 EF10 requires the .NET 10 SDK to build and requires the .NET 10 runtime to run. EF10 will not run on earlier .NET versions, and will not run on .NET Framework.
 
+The below release notes list the major improvements in the release; [the full list of issues for the release can be found here](https://github.com/dotnet/efcore/issues?q=is%3Aissue%20milestone%3A10.0.0).
+
 <a name="sql-server"></a>
 
 ## Azure SQL and SQL Server
@@ -122,9 +124,6 @@ WHERE JSON_VALUE([b].[Details], '$.Viewers' RETURNING int) > 3
 
 Note that if your EF application already uses JSON via `nvarchar` columns, these columns will be automatically changed to `json` with the first migration. You can opt out of this by manually setting the column type to `nvarchar(max)`, or configuring a compatibility level lower than 170.
 
-> [!NOTE]
-> For 10.0.0 rc1, support for the new JSON data type has been temporarily disabled for Azure SQL Database, due to lacking support. These issues are expected to be resolved by the time EF 10.0 is released, and the JSON data type will become the default until then.
-
 <a name="default-constraint-names"></a>
 
 ### Custom default constraint names
@@ -230,6 +229,12 @@ In previous versions of EF Core, evolving the model when using Azure Cosmos DB w
 
 In EF 10 we improved this experience - EF will now materialize a default value for a required property, if no data is present for it in the document, rather than throw.
 
+<a name="other-cosmos-improvements"></a>
+
+## Other Cosmos improvements
+
+- Use ExecutionStrategy for query execution (for retrying) ([#35692](https://github.com/dotnet/efcore/issues/35692)).
+
 <a name="complex-types"></a>
 
 ## Complex types
@@ -522,7 +527,7 @@ ORDER BY [b0].[Name], [b0].[Id]
 ## ExecuteUpdate support for relational JSON columns
 
 > [!NOTE]
-> ExecuteUpdate support for JSON requires mapping your types as complex types, and does not work when you types are mapped as owned entities.
+> ExecuteUpdate support for JSON requires mapping your types as complex types ([see above](#json)), and does not work when your types are mapped as owned entities.
 
 Although EF has support JSON columns for some time and allows updating them via `SaveChanges`, `ExecuteUpdate` lacked support for them. EF10 now allows referencing JSON columns and properties within them in `ExecuteUpdate`, allowing efficient bulk updating of document-modeled data within relational databases.
 
@@ -630,10 +635,64 @@ Thanks to [@aradalvand](https://github.com/aradalvand) for proposing and pushing
 
 <a name="other-improvements"></a>
 
+## Security-related improvements
+
+### Redact inlined constants from logging by default
+
+When logging executed SQL, EF does not log parameter values by default, since these may contain sensitive or personally-identifiable information (PII); <xref:Microsoft.EntityFrameworkCore.DbContextOptionsBuilder.EnableSensitiveDataLogging> can be used to enable logging parameter values in diagnostic or debugging scenarios ([see documentation](xref:core/logging-events-diagnostics/extensions-logging#sensitive-data)).
+
+However, EF sometimes inlines parameters into the SQL statement rather than sending them separately; in those scenarios, the potentially sensitive values were logged. EF10 no longer does this, redacting such inlined parameters by default and replacing them with a question mark character (`?`). For example, let's say we have a function that accepts a list of roles, and returns the list of users which have one of those roles:
+
+```c#
+Task<List<User>> GetUsersByRoles(BlogContext context, string[] roles)
+    => context.Users.Where(b => roles.Contains(b.Role)).ToListAsync();
+```
+
+Although the roles here are parameterized (may differ across invocations), we know that the actual sets of roles queried will be quite limited. We can therefore tell EF to *inline* the roles, so that the database's planner can plan execution separately for this query with its specific set of roles:
+
+```c#
+Task<List<User>> GetUsersByRoles(BlogContext context, string[] roles)
+    => context.Users.Where(b => EF.Constant(roles).Contains(b.Role)).ToListAsync();
+```
+
+On previous versions of EF, this produced the following SQL:
+
+```sql
+SELECT [u].[Id], [u].[Role]
+FROM [Users] AS [u]
+WHERE [u].[Role] IN (N'Administrator', N'Manager')
+```
+
+EF10 sends the same SQL to the database, but logs the following SQL, where the roles have been redacted:
+
+```sql
+SELECT [b].[Id], [b].[Role]
+FROM [Blogs] AS [b]
+WHERE [b].[Role] IN (?, ?)
+```
+
+If the roles represent sensitive information, this prevents that information from leaking into the application logs. As with regular parameters, full logging can be reenabled via <xref:Microsoft.EntityFrameworkCore.DbContextOptionsBuilder.EnableSensitiveDataLogging>.
+
+### Warn for string concatenation with raw SQL APIs
+
+SQL injection is one of the most serious security vulnerabilities in database applications; if unsanitized external input is inserted into SQL queries, a malicious user may be able to perform SQL injection, executing arbitrary SQL on your database. For more information about EF's SQL querying APIs and SQL injection, [see the documentation](xref:core/querying/sql-queries#passing-parameters).
+
+While EF users rarely deal with SQL directly, EF does provide SQL-based APIs for the cases where they're needed. Most of these APIs are safe in the face of SQL injection; for example <xref:Microsoft.EntityFrameworkCore.RelationalQueryableExtensions.FromSql*> accepts a .NET `FormattableString`, and any parameter will automatically be send as a separate SQL parameter, preventing SQL injection. However, in some scenarios it's necessary to build up a dynamic SQL query by piecing together multiple fragments; <xref:Microsoft.EntityFrameworkCore.RelationalQueryableExtensions.FromSqlRaw*> is designed specifically for this, and requires the user to ensure that all fragments are trusted or properly sanitized.
+
+Starting with EF10, EF has an analyzer which warns if concatenation is performed within a "raw" SQL method invocation:
+
+```c#
+var users = context.Users.FromSqlRaw("SELECT * FROM Users WHERE [" + fieldName + "] IS NULL");
+```
+
+If `fieldName` is trusted or has been properly sanitized, the warning can be safely suppressed.
+
 ## Other improvements
 
+- Stop spanning all migrations with a single transaction ([#35096](https://github.com/dotnet/efcore/issues/35096)). This reverts a change done in EF9 which caused issues in various migration scenarios.
 - Make SQL Server scaffolding compatible with Azure Data Explorer ([#34832](https://github.com/dotnet/efcore/pull/34832), contributed by [@barnuri](https://github.com/barnuri)).
 - Associate the DatabaseRoot with the scoped options instance and not the singleton options ([#34477](https://github.com/dotnet/efcore/pull/34477), contributed by [@koenigst](https://github.com/koenigst)).
-- Redact inlined constants from log when sensitive logging is off ([#35724](https://github.com/dotnet/efcore/pull/35724)).
 - Improve LoadExtension to work correctly with dotnet run and lib* named libs ([#35617](https://github.com/dotnet/efcore/pull/35617), contributed by [@krwq](https://github.com/krwq)).
 - Changes to AsyncLocal usage for better lazy loading performance ([#35835](https://github.com/dotnet/efcore/pull/35835), contributed by [@henriquewr](https://github.com/henriquewr)).
+
+[The full list of issues for the release can be found here](https://github.com/dotnet/efcore/issues?q=is%3Aissue%20milestone%3A10.0.0).
diff --git a/entity-framework/core/what-is-new/ef-core-8.0/whatsnew.md b/entity-framework/core/what-is-new/ef-core-8.0/whatsnew.md
index 3a78d2a361..e4163bf8da 100644
--- a/entity-framework/core/what-is-new/ef-core-8.0/whatsnew.md
+++ b/entity-framework/core/what-is-new/ef-core-8.0/whatsnew.md
@@ -8,7 +8,7 @@ uid: core/what-is-new/ef-core-8.0/whatsnew
 
 # What's New in EF Core 8
 
-EF Core 8.0 (EF8) was [released in November 2023](https://devblogs.microsoft.com/dotnet/announcing-ef8/).
+EF Core 8.0 (EF8) was [released in November 2023](https://devblogs.microsoft.com/dotnet/announcing-ef8/) and is a Long Term Support (LTS) release. EF8 will be supported until November 10, 2026.
 
 > [!TIP]
 > You can run and debug into the samples by [downloading the sample code from GitHub](https://github.com/dotnet/EntityFramework.Docs). Each section links to the source code specific to that section.
diff --git a/entity-framework/core/what-is-new/ef-core-9.0/whatsnew.md b/entity-framework/core/what-is-new/ef-core-9.0/whatsnew.md
index ba314af688..9607381168 100644
--- a/entity-framework/core/what-is-new/ef-core-9.0/whatsnew.md
+++ b/entity-framework/core/what-is-new/ef-core-9.0/whatsnew.md
@@ -8,7 +8,7 @@ uid: core/what-is-new/ef-core-9.0/whatsnew
 
 # What's New in EF Core 9
 
-EF Core 9 (EF9) is the next release after EF Core 8 and is scheduled for release in November 2024.
+EF Core 9.0 (EF9) was released in November 2024 and is a Short Term Support (STS) release. EF9 will be supported until November 10, 2026.
 
 EF9 is available as [daily builds](https://github.com/dotnet/efcore/blob/main/docs/DailyBuilds.md) which contain all the latest EF9 features and API tweaks. The samples here make use of these daily builds.