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/PULL_REQUEST_TEMPLATE.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
@@ -2,7 +2,7 @@
2
2
Please check whether the PR fulfills these requirements
3
3
-->
4
4
5
-
-[ ] I've read the guidelines for [contributing](CONTRIBUTING.md) and seen the [walkthrough](https://youtu.be/9OMxy1wal1s?t=1869)
5
+
-[ ] I've read the guidelines for [contributing](https://github.com/dotnet/efcore/blob/main/.github/CONTRIBUTING.md) and seen the [walkthrough](https://youtu.be/9OMxy1wal1s?t=1869)
6
6
-[ ] I've posted a comment on an issue with a detailed description of how I am planning to contribute and got approval from a member of the team
7
7
-[ ] The code builds and tests pass locally (also verified by our automated build checks)
Copy file name to clipboardExpand all lines: .github/copilot-instructions.md
+18-2Lines changed: 18 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,7 +12,7 @@ If you are not sure, do not guess, just tell that you don't know or ask clarifyi
12
12
- Use the rules defined in the .editorconfig file in the root of the repository for any ambiguous cases
13
13
- Write code that is clean, maintainable, and easy to understand
14
14
- Favor readability over brevity, but keep methods focused and concise
15
-
-Only add comments rarely to explain why a non-intuitive solution was used. The code should be self-explanatory otherwise
15
+
-**Prefer minimal comments** - The code should be self-explanatory. Add comments sparingly and only to explain *why* a non-intuitive solution was necessary, not *what* the code does. Comments are appropriate for complex logic, public APIs, or domain-specific implementations where context would otherwise be unclear
16
16
- Add license header to all files:
17
17
```
18
18
// Licensed to the .NET Foundation under one or more agreements.
@@ -48,8 +48,9 @@ If you are not sure, do not guess, just tell that you don't know or ask clarifyi
48
48
- Use `var` for local variables
49
49
- Use expression-bodied members where appropriate
50
50
- Prefer using collection expressions when possible
51
-
- Use `is` pattern matching instead of `as`and null checks
51
+
- Use `is` pattern matching instead of `as`followed by null checks (e.g., `if (obj is SomeType typed)` instead of `var typed = obj as SomeType; if (typed != null)`)
52
52
- Prefer `switch` expressions over `switch` statements when appropriate
53
+
- Prefer pattern matching with `when` clauses in switch expressions for conditional logic
53
54
- Prefer field-backed property declarations using field contextual keyword instead of an explicit field.
54
55
- Prefer range and index from end operators for indexer access
55
56
- The projects use implicit namespaces, so do not add `using` directives for namespaces that are already imported by the project
@@ -75,6 +76,7 @@ If you are not sure, do not guess, just tell that you don't know or ask clarifyi
75
76
- Use nullable reference types
76
77
- Use proper null-checking patterns
77
78
- Use the null-conditional operator (`?.`) and null-coalescing operator (`??`) when appropriate
79
+
- Don't disable nullability with a preprocessor directive (`#nullable disable`)
78
80
79
81
## Architecture and Design Patterns
80
82
@@ -89,6 +91,8 @@ If you are not sure, do not guess, just tell that you don't know or ask clarifyi
89
91
- Create both unit tests and functional tests where appropriate
90
92
- Fix `SQL` and `C#` baselines for tests when necessary by setting the `EF_TEST_REWRITE_BASELINES` env var to `1`
91
93
- Run tests with project rebuilding enabled (don't use `--no-build`) to ensure code changes are picked up
94
+
- When testing cross-platform code (e.g., file paths, path separators), verify the fix works on both Windows and Linux/macOS
95
+
- When testing `dotnet-ef` tool changes, create a test project and manually run the affected commands to verify behavior
92
96
93
97
#### Environment Setup
94
98
-**ALWAYS** run `restore.cmd` (Windows) or `. ./restore.sh` (Linux/Mac) first to restore dependencies
@@ -110,6 +114,13 @@ If you are not sure, do not guess, just tell that you don't know or ask clarifyi
110
114
-**ALL** user-facing error messages must use string resources from the `.resx` (and the generated `.Designer.cs`) file corresponding to the project
111
115
- Avoid catching exceptions without rethrowing them
112
116
117
+
## Dependency and Version Management
118
+
119
+
-**NEVER** hardcode package versions in `.csproj` files
120
+
- Check `eng/Versions.props` for existing version properties (e.g., `$(SQLitePCLRawVersion)`) before adding or updating package references
121
+
- Use `Directory.Packages.props` for NuGet package version management with Central Package Management (CPM)
122
+
- Packages listed in `eng/Version.Details.xml` are managed by Maestro dependency flow and should not be updated manually or by Dependabot
123
+
113
124
## Asynchronous Programming
114
125
115
126
- Provide both synchronous and asynchronous versions of methods where appropriate
@@ -129,6 +140,7 @@ If you are not sure, do not guess, just tell that you don't know or ask clarifyi
129
140
130
141
- Write code that is secure by default. Avoid exposing potentially private or sensitive data
131
142
- Make code NativeAOT compatible when possible. This means avoiding dynamic code generation, reflection, and other features that are not compatible with NativeAOT. If not possible, mark the code with an appropriate annotation or throw an exception
143
+
- After implementing a fix, review the surrounding code for similar patterns that might need the same change
132
144
133
145
### Entity Framework Core Specific guidelines
134
146
@@ -153,6 +165,10 @@ If you are not sure, do not guess, just tell that you don't know or ask clarifyi
153
165
- .github/: GitHub-specific files, workflows, and Copilot instructions
154
166
- .config/: AzDo pipelines configuration files
155
167
168
+
## Pull Request Guidelines
169
+
170
+
-**ALWAYS** target the `main` branch for new PRs unless explicitly instructed otherwise
171
+
156
172
## Overview of Entity Framework Core
157
173
158
174
Entity Framework Core (EF Core) is an object-database mapper for .NET. Below is a concise summary of its core architecture and concepts:
0 commit comments