Update recommendation for separate migrations projects#5284
Update recommendation for separate migrations projects#5284AndriySvyryd wants to merge 10 commits intopreview-3from
Conversation
Document complex type support for TPC/TPT See dotnet/efcore#28443 Document Cosmos bulk execution See dotnet/efcore#36599 Document Cosmos session token management See dotnet/efcore#36504 Document migration create-and-apply without recompilation See dotnet/efcore#37342 Document Cosmos transactional batches See dotnet/efcore#17308 Co-authored-by: JoasE <32096708+JoasE@users.noreply.github.com>
Co-authored-by: Shay Rojansky <roji@roji.org>
Clarify recommendation for using separate migrations projects for platform-specific cases.
There was a problem hiding this comment.
Pull request overview
Clarifies guidance in the migrations documentation about when using a separate migrations project is recommended, especially for platform-specific scenarios.
Changes:
- Updates the introductory paragraph to recommend a separate migrations project for platform-specific projects where EF tooling isn’t supported.
- Keeps the existing note about using separate migrations projects to maintain multiple migration sets.
You can also share your feedback on Copilot code review. Take the survey.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
roji
left a comment
roji
left a comment
There was a problem hiding this comment.
OK, but I admit I don't quite understand the guidance - platform-specific as in MacOS vs. Windows, or 32- vs. 64-bit? Is it just a tooling limitation of ours, and if so, would it be hard to just fix?
BTW another important scenario for a separate migrations project seems to be missing - when there's lots of (big) migrations and constantly compiling them increases the build time. Maybe extract a list of bullet points with possible reasons for doing this...
It's for WinUI, Xamarin, MAUI, Blazer, Azure Functions, etc. Also, projects that are cross-compiling to a runtime different runtime. Some of these are impossible to support with our current approach, others have very long bug tails, so some time ago (when Brice was still around) we decided that we should make the migration projects our main scenario to make the experience consistent across all project types. See dotnet/efcore#37868 |
Clarify recommendation for using separate migrations projects for platform-specific cases.