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: .github/copilot-instructions.md
+21-15Lines changed: 21 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,16 +19,17 @@ If you are not sure, do not guess, just tell that you don't know or ask clarifyi
19
19
// The .NET Foundation licenses this file to you under the MIT license.
20
20
```
21
21
- Don't add the UTF-8 BOM to files unless they have non-ASCII characters
22
-
- All types should be public. Types in .Internal namespaces should have this comment on all members:
23
-
```
22
+
- Avoid breaking public APIs. If you need to break a public API, add a new API instead and mark the old one as obsolete. Use `ObsoleteAttribute` with the message pointing to the new API
23
+
- All types should be public by default
24
+
- Types in `.Internal` namespaces or annotated with `[EntityFrameworkInternal]` require this XML doc comment on ALL members:
25
+
```csharp
24
26
/// <summary>
25
27
/// This is an internal API that supports the Entity Framework Core infrastructure and not subject to
26
28
/// the same compatibility standards as public APIs. It may be changed or removed without notice in
27
29
/// any release. You should only use it directly in your code with extreme caution and knowing that
28
30
/// doing so can result in application failures when updating to a new Entity Framework Core release.
29
31
/// </summary>
30
32
```
31
-
- Avoid breaking public APIs. If you need to break a public API, add a new API instead and mark the old one as obsolete. Use `ObsoleteAttribute` with the message pointing to the new API
32
33
33
34
### Formatting
34
35
@@ -87,8 +88,12 @@ If you are not sure, do not guess, just tell that you don't know or ask clarifyi
87
88
- Follow the existing test patterns in the corresponding test projects
88
89
- Create both unit tests and functional tests where appropriate
89
90
- Fix `SQL` and `C#` baselines for tests when necessary by setting the `EF_TEST_REWRITE_BASELINES` env var to `1`
90
-
- Before building or running the tests execute `restore.cmd` or `restore.sh` and `activate.ps1` or `activate.sh` to set up the environment
91
-
- When running the tests specify the test project and let it be rebuilt by not adding `--no-build`
91
+
- Run tests with project rebuilding enabled (don't use `--no-build`) to ensure code changes are picked up
92
+
93
+
#### Environment Setup
94
+
-**ALWAYS** run `restore.cmd` (Windows) or `. ./restore.sh` (Linux/Mac) first to restore dependencies
95
+
-**ALWAYS** run `. .\activate.ps1` (PowerShell) or `. ./activate.sh` (Bash) to set up the development environment with correct SDK versions before building or running the tests
96
+
- These scripts set `DOTNET_ROOT`, `DOTNET_MULTILEVEL_LOOKUP`, and PATH for the project's specific .NET SDK version
92
97
93
98
## Documentation
94
99
@@ -102,7 +107,7 @@ If you are not sure, do not guess, just tell that you don't know or ask clarifyi
102
107
## Error Handling
103
108
104
109
- Use appropriate exception types.
105
-
-Include helpful error messages stored in the .resx file corresponding to the project
110
+
-**ALL** user-facing error messages must use string resources from the `.resx` (and the generated `.Designer.cs`) file corresponding to the project
106
111
- Avoid catching exceptions without rethrowing them
107
112
108
113
## Asynchronous Programming
@@ -127,18 +132,15 @@ If you are not sure, do not guess, just tell that you don't know or ask clarifyi
127
132
128
133
### Entity Framework Core Specific guidelines
129
134
130
-
- Follow the provider pattern when extending EF Core's capabilities for specific databases
131
-
- Follow the existing model building design patterns
132
-
- Add corresponding methods to the `*Builder`, `*Configuration`, `*Extensions`, `IConvention*Builder`, `IReadOnly*`, `IMutable*`and `IConvention*` types as needed
133
-
- Make corresponding changes to the `Runtime*` types as needed.
134
-
- For Relational-specific model changes also modify the `RelationalModel` and `*AnnotationProvider` types.
135
-
- Make corresponding changes to the `CSharpRuntimeModelCodeGenerator`, `*CSharpRuntimeAnnotationCodeGenerator` and `CSharpDbContextGenerator` types as needed
136
-
- Use the logging infrastructure for diagnostics
135
+
- Use the logging infrastructure for diagnostics and interception
137
136
- Prefer using `Check.DebugAssert` instead of `Debug.Assert` or comments
138
137
- Use `Check.NotNull` and `Check.NotEmpty` for preconditions in public APIs
138
+
- The methods in `Check` class use `[CallerArgumentExpression]` to automatically capture parameter names
139
139
- Unit tests should build the model using the corresponding `*TestHelpers.Instance.CreateConventionBuilder()` model and finalizing it
140
-
- The services should be resolved from the `IServiceProvider` returned by `*TestHelpers.Instance.CreateContextServices`, note that it has overloads allowing to specify the model and mock services
140
+
- The services in unit tests should be resolved from the `IServiceProvider` returned by `*TestHelpers.Instance.CreateContextServices`, note that it has overloads allowing to specify the model and mock services
141
141
- For functional tests, create tests in projects corresponding to the database providers that derive from the appropriate test base classes in the `EFCore.*Specification.Tests` projects
142
+
- Each provider has its own project structure: `EFCore.{Provider}`, `EFCore.{Provider}.Tests`, `EFCore.{Provider}.FunctionalTests`
0 commit comments