Merge pull request #5221 from dotnet/main

Auto Publish – main to live - 2026-01-05 23:00 UTC

Author: learn-build-service-prod[bot]

entity-framework/core/providers/sql-server/index.md

@@ -51,6 +51,8 @@ builder.Services.AddDbContext<MyContext>(options =>
     options.UseSqlServer(builder.Configuration.GetConnectionString("MyContext")));
 ```
 
+The EF SQL Server provider uses [Microsoft.Data.SqlClient](/sql/connect/ado-net/overview-sqlclient-driver) as its underlying ADO.NET provider. For more information on the connection strings accepted by SqlClient, [see this page](/sql/connect/ado-net/connection-string-syntax).
+
 ### [Azure SQL](#tab/azure-sql)
 
 ```c#

entity-framework/core/querying/tags.md

@@ -68,6 +68,27 @@ FROM [People] AS [p]
 ORDER BY [p].[Location].STDistance(@__myLocation_0) DESC
 ```
 
+## Tagging with file name and line number
+
+Queries can be automatically tagged with the file name and line number where the LINQ query is defined in source code. This is done using the <xref:Microsoft.EntityFrameworkCore.EntityFrameworkQueryableExtensions.TagWithCallSite*> method:
+
+```csharp
+var myLocation = new Point(1, 2);
+var closestPeople = await (from f in context.People.TagWithCallSite()
+                     orderby f.Location.Distance(myLocation) descending
+                     select f).Take(5).ToListAsync();
+```
+
+This query translates to (the actual line number will reflect where the query is defined in the source file):
+
+```sql
+-- file: C:\Work\EntityFramework.Docs\samples\Program.cs:23
+
+SELECT TOP(@__p_1) [p].[Id], [p].[Location]
+FROM [People] AS [p]
+ORDER BY [p].[Location].STDistance(@__myLocation_0) DESC
+```
+
 ## Known limitations
 
 **Query tags aren't parameterizable:**

entity-framework/core/testing/choosing-a-testing-strategy.md

@@ -21,7 +21,7 @@ However, tests which pass against a test double don't guarantee that your progra
 
 Because of the above difficulties with testing against a real database, developers are frequently urged to use test doubles first, and have a robust test suite which they can run frequently on their machines; tests involving the database, in contrast, are supposed to be executed much less frequently, and in many cases also provide far less coverage. We recommend giving more thought to the latter, and suggest that databases may actually be far less affected by the above problems than people tend to think:
 
-1. Most databases can nowadays be easily installed on the developer's machine. Container-based technologies such as Docker can make this very easy, and technologies such as [Github Workspaces](https://docs.github.com/en/codespaces/overview) and [Dev Container](https://code.visualstudio.com/docs/remote/create-dev-container) set up your entire development environment for you (including the database). When using SQL Server, it's also possible to test against [LocalDB](/sql/database-engine/configure-windows/sql-server-express-localdb) on Windows, or easily set up a Docker image on Linux.
+1. Most databases can nowadays be easily installed on the developer's machine. Container-based technologies such as Docker can make this very easy, and libraries like [Testcontainers](https://testcontainers.com/modules/dotnet/) can help automate the lifecycle of containerized databases in your tests. Technologies such as [GitHub Workspaces](https://docs.github.com/en/codespaces/overview) and [Dev Container](https://code.visualstudio.com/docs/remote/create-dev-container) set up your entire development environment for you (including the database). When using SQL Server, it's also possible to test against [LocalDB](/sql/database-engine/configure-windows/sql-server-express-localdb) on Windows, or easily set up a Docker image on Linux.
 2. Testing against a local database - with a reasonable test dataset - is usually extremely fast: communication is completely local, and test data is typically buffered in memory on the database side. EF Core itself contains over 30,000 tests against SQL Server alone; these complete reliably in a few minutes, execute in CI on every single commit, and are very frequently executed by developers locally. Some developers turn to an in-memory database (a "fake") in the belief that this is needed for speed - this is almost never actually the case.
 3. Isolation is indeed a hurdle when running tests against a real database, as tests may modify data and interfere with one another. However, there are various techniques to provide isolation in database testing scenarios; we concentrate on these in [Testing against your production database system](xref:core/testing/testing-with-the-database)).
 

entity-framework/core/testing/testing-with-the-database.md

@@ -16,7 +16,7 @@ The main hurdle with testing which involves a real database is to ensure proper
 
 ## Setting up your database system
 
-Most database systems nowadays can be easily installed, both in CI environments and on developer machines. While it's frequently easy enough to install the database via the regular installation mechanism, ready-to-use Docker images are available for most major databases and can make installation particularly easy in CI. For the developer environment, [GitHub Workspaces](https://docs.github.com/en/codespaces/overview), [Dev Container](https://code.visualstudio.com/docs/remote/create-dev-container) can set up all needed services and dependencies - including the database. While this requires an initial investment in setup, once that's done you have a working testing environment and can concentrate on more important things.
+Most database systems nowadays can be easily installed, both in CI environments and on developer machines. While it's frequently easy enough to install the database via the regular installation mechanism, ready-to-use Docker images are available for most major databases and can make installation particularly easy in CI. Libraries like [Testcontainers](https://testcontainers.com/modules/dotnet/) can further simplify this by automatically managing containerized database instances during testing. For the developer environment, [GitHub Workspaces](https://docs.github.com/en/codespaces/overview), [Dev Container](https://code.visualstudio.com/docs/remote/create-dev-container) can set up all needed services and dependencies - including the database. While this requires an initial investment in setup, once that's done you have a working testing environment and can concentrate on more important things.
 
 In certain cases, databases have a special edition or version which can be helpful for testing. When using SQL Server, [LocalDB](/sql/database-engine/configure-windows/sql-server-express-localdb) can be used to run tests locally with virtually no setup at all, spinning up the database instance on demand and possibly saving resources on less powerful developer machines. However, LocalDB is not without its issues: