You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: entity-framework/core/cli/powershell.md
+5-3Lines changed: 5 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,7 +11,9 @@ The Package Manager Console (PMC) tools for Entity Framework Core perform design
11
11
12
12
If you aren't using Visual Studio, we recommend the [EF Core Command-line Tools](xref:core/cli/dotnet) instead. The .NET Core CLI tools are cross-platform and run inside a command prompt.
| <nobr>`-Connection <String>`</nobr> | The connection string to the database. For ASP.NET Core 2.x projects, the value can be *name=\<name of connection string>*. In that case the name comes from the configuration sources that are set up for the project. This is a positional parameter and is required. |
220
+
| <nobr>`-Connection <String>`</nobr> | The connection string to the database. The value can be *name=\<name of connection string>*. In that case the name comes from the [configuration sources](xref:core/miscellaneous/connection-strings#aspnet-core) that are set up for the project. This is a positional parameter and is required. |
219
221
| <nobr>`-Provider <String>`</nobr> | The provider to use. Typically this is the name of the NuGet package, for example: `Microsoft.EntityFrameworkCore.SqlServer`. This is a positional parameter and is required. |
220
222
| <nobr>`-OutputDir <String>`</nobr> | The directory to put entity class files in. Paths are relative to the project directory. |
221
223
| <nobr>`-ContextDir <String>`</nobr> | The directory to put the `DbContext` file in. Paths are relative to the project directory. |
The lifetime of a `DbContext` begins when the instance is created and ends when the instance is [disposed](/dotnet/standard/garbage-collection/unmanaged). A `DbContext` instance is designed to be used for a _single_[unit-of-work](https://www.martinfowler.com/eaaCatalog/unitOfWork.html). This means that the lifetime of a `DbContext` instance is usually very short.
@@ -29,15 +31,17 @@ A typical unit-of-work when using Entity Framework Core (EF Core) involves:
29
31
30
32
> [!IMPORTANT]
31
33
>
32
-
> - It is very important to dispose the <xref:Microsoft.EntityFrameworkCore.DbContext> after use. This ensures both that any unmanaged resources are freed, and that any events or other hooks are unregistered so as to prevent memory leaks in case the instance remains referenced.
33
-
> -[DbContext is **not thread-safe**](#avoiding-dbcontext-threading-issues). Do not share contexts between threads. Make sure to [await](/dotnet/csharp/language-reference/operators/await) all async calls before continuing to use the context instance.
34
+
> - It is important to dispose the <xref:Microsoft.EntityFrameworkCore.DbContext> after use. This ensures any:
35
+
> - Unmanaged resources are freed.
36
+
> - Events or other hooks are unregistered. Unregistering prevents memory leaks when the instance remains referenced.
37
+
> -[DbContext is **Not thread-safe**](#avoiding-dbcontext-threading-issues). Don't share contexts between threads. Make sure to [await](/dotnet/csharp/language-reference/operators/await) all async calls before continuing to use the context instance.
34
38
> - An <xref:System.InvalidOperationException> thrown by EF Core code can put the context into an unrecoverable state. Such exceptions indicate a program error and are not designed to be recovered from.
35
39
36
40
## DbContext in dependency injection for ASP.NET Core
37
41
38
42
In many web applications, each HTTP request corresponds to a single unit-of-work. This makes tying the context lifetime to that of the request a good default for web applications.
39
43
40
-
ASP.NET Core applications are [configured using dependency injection](/aspnet/core/fundamentals/startup). EF Core can be added to this configuration using <xref:Microsoft.Extensions.DependencyInjection.EntityFrameworkServiceCollectionExtensions.AddDbContext%2A> in the [`ConfigureServices`](/aspnet/core/fundamentals/startup#the-configureservices-method) method of `Startup.cs`. For example:
44
+
ASP.NET Core applications are [configured using dependency injection](/aspnet/core/fundamentals/startup). EF Core can be added to this configuration using <xref:Microsoft.Extensions.DependencyInjection.EntityFrameworkServiceCollectionExtensions.AddDbContext%2A> in `Program.cs`. For example:
41
45
42
46
<!--
43
47
public void ConfigureServices(IServiceCollection services)
@@ -48,9 +52,10 @@ ASP.NET Core applications are [configured using dependency injection](/aspnet/co
This example registers a `DbContext` subclass called `ApplicationDbContext` as a scoped service in the ASP.NET Core application service provider (a.k.a. the dependency injection container). The context is configured to use the SQL Server database provider and will read the connection string from ASP.NET Core configuration. It typically does not matter _where_ in `ConfigureServices` the call to `AddDbContext` is made.
The preceding code registers `ApplicationDbContext`, a subclass of `DbContext`, as a scoped service in the ASP.NET Core app service provider. The service provider is also known as the dependency injection container. The context is configured to use the SQL Server database provider and reads the connection string from ASP.NET Core configuration.
54
59
55
60
The `ApplicationDbContext` class must expose a public constructor with a `DbContextOptions<ApplicationDbContext>` parameter. This is how context configuration from `AddDbContext` is passed to the `DbContext`. For example:
56
61
@@ -63,9 +68,10 @@ The `ApplicationDbContext` class must expose a public constructor with a `DbCont
`ApplicationDbContext` can then be used in ASP.NET Core controllers or other services through constructor injection. For example:
74
+
`ApplicationDbContext` can be used in ASP.NET Core controllers or other services through constructor injection:
69
75
70
76
<!--
71
77
public class MyController
@@ -82,13 +88,13 @@ The `ApplicationDbContext` class must expose a public constructor with a `DbCont
82
88
83
89
The final result is an `ApplicationDbContext` instance created for each request and passed to the controller to perform a unit-of-work before being disposed when the request ends.
84
90
85
-
Read further in this article to learn more about configuration options. In addition, see [App startup in ASP.NET Core](/aspnet/core/fundamentals/startup) and [Dependency injection in ASP.NET Core](/aspnet/core/fundamentals/dependency-injection) for more information on configuration and dependency injection in ASP.NET Core.
91
+
Read further in this article to learn more about configuration options. See [Dependency injection in ASP.NET Core](/aspnet/core/fundamentals/dependency-injection) for more information.
86
92
87
93
<!-- See also [Using Dependency Injection](TODO) for advanced dependency injection configuration with EF Core. -->
88
94
89
-
## Simple DbContext initialization with 'new'
95
+
## Basic DbContext initialization with 'new'
90
96
91
-
`DbContext` instances can be constructed in the normal .NET way, for example with `new` in C#. Configuration can be performed by overriding the `OnConfiguring` method, or by passing options to the constructor. For example:
97
+
`DbContext` instances can be constructed with `new` in C#. Configuration can be performed by overriding the `OnConfiguring` method, or by passing options to the constructor. For example:
92
98
93
99
<!--
94
100
public class ApplicationDbContext : DbContext
@@ -145,7 +151,7 @@ The `DbContextOptions` can be created and the constructor can be called explicit
Some application types (e.g. [ASP.NET Core Blazor](/aspnet/core/blazor/)) use dependency injection but do not create a service scope that aligns with the desired `DbContext` lifetime. Even where such an alignment does exist, the application may need to perform multiple units-of-work within this scope. For example, multiple units-of-work within a single HTTP request.
Copy file name to clipboardExpand all lines: entity-framework/core/includes/managed-identities-test-non-production.md
+2-1Lines changed: 2 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,6 +4,7 @@ author: rick-anderson
4
4
ms.author: riande
5
5
ms.date: 10/23/2024
6
6
ms.topic: include
7
+
title: an include file
7
8
---
8
9
> [!WARNING]
9
-
> This article uses a local database that doesn't require the user to be authenticated. Production apps should use the most secure authentication flow available. For more information on authentication for deployed test and production apps, see [Secure authentication flows](xref:security/index#secure-authentication-flows).
10
+
> This article uses a local database that doesn't require the user to be authenticated. Production apps should use the most secure authentication flow available. For more information on authentication for deployed test and production apps, see [Secure authentication flows](/aspnet/core/security/#secure-authentication-flows).
Copy file name to clipboardExpand all lines: entity-framework/core/index.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -50,7 +50,7 @@ While EF Core is good at abstracting many programming details, there are some be
50
50
* Find issues in the app that only show up when using a specific versions or edition of the database server.
51
51
* Catch breaking changes when upgrading EF Core and other dependencies. For example, adding or upgrading frameworks like ASP.NET Core, OData, or AutoMapper. These dependencies can affect EF Core in unexpected ways.
52
52
* Performance and stress testing with representative loads. The naïve usage of some features doesn't scale well. For example, multiple collections Includes, heavy use of lazy loading, conditional queries on non-indexed columns, massive updates and inserts with store-generated values, lack of concurrency handling, large models, inadequate cache policy.
53
-
* Security review: For example, handling of connection strings and other secrets, database permissions for non-deployment operation, input validation for raw SQL, encryption for sensitive data.
53
+
* Security review: For example, handling of connection strings and other secrets, database permissions for non-deployment operation, input validation for raw SQL, encryption for sensitive data. See [Secure authentication flows](/aspnet/core/security/#secure-authentication-flows) for secure configuration and authentication flow.
54
54
* Make sure logging and diagnostics are sufficient and usable. For example, appropriate logging configuration, query tags, and Application Insights.
55
55
* Error recovery. Prepare contingencies for common failure scenarios such as version rollback, fallback servers, scale-out and load balancing, DoS mitigation, and data backups.
56
56
* Application deployment and migration. Plan out how migrations are going to be applied during deployment; doing it at application start can suffer from concurrency issues and requires higher permissions than necessary for normal operation. Use staging to facilitate recovery from fatal errors during migration. For more information, see [Applying Migrations](xref:core/managing-schemas/migrations/applying).
Reverse engineering is the process of scaffolding entity type classes and a `DbContext` class based on a database schema. It can be performed using the `Scaffold-DbContext` command of the EF Core Package Manager Console (PMC) tools or the `dotnet ef dbcontext scaffold` command of the .NET Command-line Interface (CLI) tools.
10
+
Reverse engineering is the process of scaffolding entity type classes and a [DbContext](/dotnet/api/microsoft.entityframeworkcore.dbcontext) class based on a database schema. It can be performed using the `Scaffold-DbContext` command of the EF Core Package Manager Console (PMC) tools or the `dotnet ef dbcontext scaffold` command of the .NET Command-line Interface (CLI) tools.
11
11
12
12
> [!NOTE]
13
13
> The scaffolding of a `DbContext` and entity types documented here is distinct from the [scaffolding of controllers in ASP.NET Core](/aspnet/mvc/overview/getting-started/introduction/adding-a-controller) using Visual Studio, which is not documented here.
@@ -27,9 +27,11 @@ Both the PMC and the .NET CLI commands have two required arguments: the connecti
27
27
28
28
### Connection string
29
29
30
-
The first argument to the command is a connection string to the database. The tools will use this connection string to read the database schema.
How you quote and escape the connection string depends on which shell you are using to execute the command; refer to your shell's documentation for more information. For example, PowerShell requires you to escape the `$` character, but not `\`.
32
+
The first argument to the command is a connection string to the database. The tools use this connection string to read the database schema.
33
+
34
+
How the connection string is quoted and escaped depends on the shell that is used to run the command. Refer to the shell's documentation. For example, PowerShell requires escaping `$`, but not `\`.
33
35
34
36
The following example scaffolds entity types and a `DbContext` from the `Chinook` database located on the machine's SQL Server LocalDB instance, making use of the `Microsoft.EntityFrameworkCore.SqlServer` database provider.
Many line of business applications are designed to work with multiple customers. It is important to secure the data so that customer data isn't "leaked" or seen by other customers and potential competitors. These applications are classified as "multi-tenant" because each customer is considered a tenant of the application with their own set of data.
> This document provides examples and solutions "as is." These are not intended to be "best practices" but rather "working practices" for your consideration.
Copy file name to clipboardExpand all lines: entity-framework/ef6/fundamentals/configuring/config-file.md
+10-1Lines changed: 10 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,16 @@ ms.date: 10/23/2016
6
6
uid: ef6/fundamentals/configuring/config-file
7
7
---
8
8
# Configuration File Settings
9
-
Entity Framework allows a number of settings to be specified from the configuration file. In general EF follows a ‘convention over configuration’ principle: all the settings discussed in this post have a default behavior, you only need to worry about changing the setting when the default no longer satisfies your requirements.
9
+
Entity Framework allows a number of settings to be specified from the configuration file. In general EF follows a ‘convention over configuration’ principle: all the settings discussed in this post have a default behavior, you only need to worry about changing the setting when the default no longer satisfies your requirements.
10
+
11
+
## Configuration data guidelines
12
+
13
+
* Never store passwords or other sensitive data in configuration provider code or in plain text configuration files.
14
+
* Don't use production secrets in development or test environments.
15
+
* Specify secrets outside of the project so that they can't be accidentally committed to a source code repository.
16
+
* Consider protecting the contents of the configuration file using [Protected Configuration](/dotnet/framework/data/adonet/connection-strings-and-configuration-files#encrypt-configuration-file-sections-using-protected-configuration).
This topic covers how Entity Framework discovers which database connection to use, and how you can change it. Models created with Code First and the EF Designer are both covered in this topic.
9
+
This article covers how Entity Framework discovers which database connection to use, and how to change it. Models created with Code First and the EF Designer are covered.
10
10
11
-
Typically an Entity Framework application uses a class derived from DbContext. This derived class will call one of the constructors on the base DbContext class to control:
- How the context will connect to a database — that is, how a connection string is found/used
14
-
- Whether the context will use calculate a model using Code First or load a model created with the EF Designer
13
+
14
+
Typically an Entity Framework application uses a class derived from DbContext. This derived class calls one of the constructors on the base DbContext class to control:
15
+
16
+
- How the context connects to a database, that is, how a connection string is found and used.
17
+
- Whether the context calculates a model using Code First or loads a model created with the EF Designer.
15
18
- Additional advanced options
16
19
17
20
The following fragments show some of the ways the DbContext constructors can be used.
0 commit comments