Address review comments

entity-framework/core/miscellaneous/nativeaot-and-precompiled-queries.md → entity-framework/core/performance/nativeaot-and-precompiled-queries.md

@@ -3,7 +3,7 @@ title: NativeAOT Support and Precompiled Queries (Experimental) - EF Core
 description: Publishing NativeAOT Entity Framework Core applications and using precompiled queries
 author: roji
 ms.date: 11/10/2024
-uid: core/miscellaneous/nativeaot-and-precompiled-queries
+uid: core/performance/nativeaot-and-precompiled-queries
 ---
 # NativeAOT Support and Precompiled Queries (Experimental)
 
@@ -16,7 +16,7 @@ uid: core/miscellaneous/nativeaot-and-precompiled-queries
 * Small, self-contained binaries that have smaller memory footprints and are easier to deploy
 * Running applications in environments where just-in-time compilation isn't supported
 
-EF NativeAOT applications start up much faster than the same applications without NativeAOT; aside from the general startup improvements that NativeAOT offers (i.e. no JIT compilation required on each startup), EF's NativeAOT supports removes the processing of LINQ queries and their translation to SQL; the more EF LINQ queries an application has in its code, the faster the startup gains are expected to be from NativeAOT.
+EF applications published with NativeAOT start up much faster than the same applications without it. In addition to the general .NET startup improvements that NativeAOT offers (i.e. no JIT compilation required each time), EF also precompiles LINQ queries when publishing your application, so that no processing is needed when starting up and the SQL is already available for immediate execution. The more EF LINQ queries an application has in its code, the faster the startup gains are expected to be.
 
 ## Publishing an EF NativeAOT Application
 
@@ -38,10 +38,10 @@ C# interceptors are currently an experimental feature, and require a special opt
 </PropertyGroup>
 ```
 
-At this point, you're ready to precompile your LINQ queries, and generate the [compiled model](xref:core/performance/advanced-performance-topics#compiled-models) that they depend on. Make sure that you have at least version 9.0 of the EF tools (`dotnet tool list -g`), and then execute the following:
+Finally, the [`Microsoft.EntityFrameworkCore.Tasks`](https://www.nuget.org/packages/Microsoft.EntityFrameworkCore.Tasks) package contains MSBuild integration that will perform the query precompilation (and generate the required compiled model) when you publish your application:
 
-```console
-dotnet ef dbcontext optimize --precompile-queries --nativeaot
+```xml
+<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="..." />
 ```
 
 You're now ready to publish your EF NativeAOT application:
@@ -50,7 +50,7 @@ You're now ready to publish your EF NativeAOT application:
 dotnet publish -r linux-arm64 -c Release
 ```
 
-This shows publishing a NativeAOT publishing for Linux running on ARM64; [consult this catalog](/dotnet/core/rid-catalog) to find your runtime identifier.
+This shows publishing a NativeAOT publishing for Linux running on ARM64; [consult this catalog](/dotnet/core/rid-catalog) to find your runtime identifier. If you'd like to generate the interceptors without publishing - for example to examine the generated sources - you can do so via the `net ef dbcontext optimize --precompile-queries --nativeaot` command.
 
 Due to the way C# interceptors work, any change in the application source invalidates them and requires repeating the above process. As a result, interceptor generation and actual publishing aren't expected to happen in the inner loop, as the developer is working on code; instead, both `dotnet ef dbcontext optimize` and `dotnet publish` can be executed in a publishing/deployment workflow, in a CI/CD system.
 

entity-framework/core/what-is-new/ef-core-9.0/whatsnew.md

@@ -297,17 +297,17 @@ Note, however, that we plan to fully remove sync support in EF 11, so start upda
 ## AOT and pre-compiled queries
 
 > [!WARNING]
-> NativeAOT and query precompilation are highly experimental feature, and are not yet suited for production use. The support described below should be viewed as infrastructure towards the final feature, which will likely be released with EF 10. We encourage you to experiment with the current support and report on your experiences, but recommend against deploying EF NativeAOT applications in production.
+> NativeAOT and query precompilation are highly experimental features, and are not yet suited for production use. The support described below should be viewed as infrastructure towards the final feature, which will likely be released with EF 10. We encourage you to experiment with the current support and report on your experiences, but recommend against deploying EF NativeAOT applications in production.
 
-EF 9.0 brings initial, experimental support for [.NET NativeAOT](/dotnet/core/deploying/native-aot), allowing the publishing of ahead-of-time compiled applications which make use of EF to access databases. To support LINQ queries in NativeAOT mode, EF reiles on _query precompilation_: this mechanism statically identifies EF LINQ queries and generates C# [_interceptors_](/dotnet/csharp/whats-new/csharp-12#interceptors), which contain code to execute each specific query. This can significantly cut down on your application's startup time, as the heavy lifting of processing and compiling your LINQ queries into SQL no longer happens every time your application starts up. Instead, each query's interceptor contains the finalized SQL for that query, as well as optimized code to materialize database results as .NET objects.
+EF 9.0 brings initial, experimental support for [.NET NativeAOT](/dotnet/core/deploying/native-aot), allowing the publishing of ahead-of-time compiled applications which make use of EF to access databases. To support LINQ queries in NativeAOT mode, EF relies on _query precompilation_: this mechanism statically identifies EF LINQ queries and generates C# [_interceptors_](/dotnet/csharp/whats-new/csharp-12#interceptors), which contain code to execute each specific query. This can significantly cut down on your application's startup time, as the heavy lifting of processing and compiling your LINQ queries into SQL no longer happens every time your application starts up. Instead, each query's interceptor contains the finalized SQL for that query, as well as optimized code to materialize database results as .NET objects.
 
 For example, given a program with the following EF query:
 
 ```c#
 var blogs = await context.Blogs.Where(b => b.Name == "foo").ToListAsync();
 ```
 
-EF will generate a C# interceptor into your project, which will take over the query execution. Instead of processing the query and translating it to SQL every time the program starts, the interceptor has the SQL embedded right into it, allowing your program to start up much faster:
+EF will generate a C# interceptor into your project, which will take over the query execution. Instead of processing the query and translating it to SQL every time the program starts, the interceptor has the SQL embedded right into it (for SQL Server in this case), allowing your program to start up much faster:
 
 ```c#
 var relationalCommandTemplate = ((IRelationalCommandTemplate)(new RelationalCommand(materializerLiftableConstantContext.CommandBuilderDependencies, "SELECT [b].[Id], [b].[Name]\nFROM [Blogs] AS [b]\nWHERE [b].[Name] = N'foo'", new IRelationalParameter[] { })));
@@ -323,9 +323,9 @@ UnsafeAccessor_Blog_Name_Set(instance) = dataReader.GetString(1);
 
 This uses another new .NET feature - [unsafe accessors](/dotnet/api/system.runtime.compilerservices.unsafeaccessorattribute), to inject data from the database into your object's private fields.
 
-If you're interested in NativeAOT and like to experiment with cutting-edge features, give this a try! Just be aware that the feature should be consider unstable, and currently has many limitations; we expect to stabilize it and make it more suitable for production usage in EF 10.
+If you're interested in NativeAOT and like to experiment with cutting-edge features, give this a try! Just be aware that the feature should be considered unstable, and currently has many limitations; we expect to stabilize it and make it more suitable for production usage in EF 10.
 
-See the [NativeAOT documentation page](xref:core/miscellaneous/nativeaot-and-precompiled-queries) for more details.
+See the [NativeAOT documentation page](xref:core/performance/nativeaot-and-precompiled-queries) for more details.
 
 ## LINQ and SQL translation
 

entity-framework/toc.yml

@@ -350,6 +350,8 @@
         href: core/performance/efficient-updating.md
       - name: Modeling for performance
         href: core/performance/modeling-for-performance.md
+      - name: NativeAOT and precompiled queries
+        href: core/performance/nativeaot-and-precompiled-queries.md
       - name: Advanced performance topics
         href: core/performance/advanced-performance-topics.md
 
@@ -365,8 +367,6 @@
         href: core/miscellaneous/collations-and-case-sensitivity.md
       - name: Connection resiliency
         href: core/miscellaneous/connection-resiliency.md
-      - name: NativeAOT and precompiled queries
-        href: core/miscellaneous/nativeaot-and-precompiled-queries.md
       - name: Connection strings
         href: core/miscellaneous/connection-strings.md
       - name: Context pooling