/entity-framework6
Maintain or migrate EF6-based applications with realistic guidance on what to keep, what to modernize, and when EF Core is or is not the right next step. USE FOR: EF6 codebases; runtime versus ORM migration decisions; EDMX, code-first, ObjectContext, and legacy data-access
$ npx -y skills add managedcode/dotnet-skills --skill entity-framework6 --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/entity-framework6
Context preview
The summary Claude sees to decide when to auto-load this skill.
Maintain or migrate EF6-based applications with realistic guidance on what to keep, what to modernize, and when EF Core is or is not the right next step. USE FOR: EF6 codebases; runtime versus ORM migration decisions; EDMX, code-first, ObjectContext, and legacy data-access
SKILL.md
entity-framework6.SKILL.mdname: entity-framework6
description: "Maintain or migrate EF6-based applications with realistic guidance on what to keep, what to modernize, and when EF Core is or is not the right next step. USE FOR: EF6 codebases; runtime versus ORM migration decisions; EDMX, code-first, ObjectContext, and legacy data-access review. DO NOT USE FOR: unrelated stacks; generic tasks that do not need this specific guidance. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made."
compatibility: "Requires EF6 or a transition plan from EF6 to EF Core or modern .NET."
Entity Framework 6
Trigger On
- working in an EF6 codebase on .NET Framework or modern .NET
- deciding whether to keep EF6, move to modern .NET runtime, or port to EF Core
- reviewing EDMX, code-first, or legacy ASP.NET/WPF/WinForms data access
- planning a data layer migration strategy
Workflow
1. **Audit current EF6 usage** before planning any migration. Identify which features the codebase depends on:
// Common EF6-specific patterns to inventory:
// - EDMX designer models (check for *.edmx files)
// - ObjectContext vs DbContext usage
// - Lazy loading with virtual navigation properties
// - Database.SqlQuery<T>() for raw SQL
// - Stored procedure mappings in model
// - Spatial types (DbGeography, DbGeometry)
2. **Decide runtime vs ORM migration separately:**
| Path | When to use | |------|-------------| | Keep EF6 on .NET Framework | Legacy app with no runtime pressure | | EF6 on modern .NET | Runtime upgrade needed, ORM migration too risky | | EF6 → EF Core | Clean data layer, no EDMX, minimal stored-procedure mapping |
3. **For maintenance work** — keep EF6 stable:
- use repository + unit of work patterns to isolate data access (see [references/patterns.md](references/patterns.md))
- prefer `DbContext` over `ObjectContext` for new code
- use `AsNoTracking()` for read-only queries
- configure concurrency tokens with `[ConcurrencyCheck]` or `IsRowVersion()`
4. **For migration work** — validate each slice:
- map EF6 features to EF Core equivalents (see [references/migration.md](references/migration.md))
- migrate one bounded context at a time, not the entire data layer
- run integration tests against the real database provider, not InMemory
- verify: `dotnet ef migrations add` succeeds, queries produce equivalent results, lazy loading behavior matches expectations
5. **Do not promise EF Core features to EF6 codebases** — EF6 is stable and supported but not on the innovation path. Keep expectations realistic.
Current Upstream Notes
- The July 2026 EF Core vs EF6 comparison refresh keeps the ORM migration decision separate from runtime modernization. EF6 can remain the right ORM when EDMX, ObjectContext, or complex legacy mappings dominate the risk.
- EF Core `v10.0.10` servicing does not change EF6 guidance by itself; only move an EF6 codebase when the project has a bounded migration slice and database-backed equivalence tests.
flowchart LR
A["Audit EF6 usage"] --> B{"EDMX or complex mappings?"}
B -->|Yes| C["High migration cost — consider keeping EF6"]
B -->|No| D["Evaluate EF Core migration"]
D --> E["Migrate one context at a time"]
E --> F["Integration test against real DB"]
C --> G["Modernize runtime only"]
F --> H["Validate query equivalence"]
G --> HDeliver
- realistic EF6 maintenance or migration guidance based on actual codebase audit
- clear separation between runtime upgrade and ORM upgrade work
- bounded migration slices with concrete validation checkpoints
- reduced risk for legacy data access changes
Validate
- EF6 feature inventory is complete before migration planning starts
- migration assumptions are backed by real feature usage, not guesses
- EF6-only features (EDMX, spatial types, ObjectContext patterns) are identified early
- integration tests run against the real database provider, not mocks or InMemory
- the proposed path avoids unnecessary churn in stable data access code
References
- [references/migration.md](references/migration.md) - decision framework, migration approaches, EF6-to-EF Core feature mapping, and common pitfalls
- [references/patterns.md](references/patterns.md) - repository and unit of work patterns, query optimization, concurrency handling, auditing, and testing strategies for EF6 codebases
Read more
name: entity-framework6 description: "Maintain or migrate EF6-based applications with realistic guidance on what to keep, what to modernize, and when EF Core is or is not the right next step. USE FOR: EF6 codebases; runtime versus ORM migration decisions; EDMX, code-first, ObjectContext, and legacy data-access review. DO NOT USE FOR: unrelated stacks; generic tasks that do not need this specific guidance. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made." compatibility: "Requires EF6 or a transition plan from EF6 to EF Core or modern .NET."
Entity Framework 6
Trigger On
- working in an EF6 codebase on .NET Framework or modern .NET
- deciding whether to keep EF6, move to modern .NET runtime, or port to EF Core
- reviewing EDMX, code-first, or legacy ASP.NET/WPF/WinForms data access
- planning a data layer migration strategy
Workflow
1. **Audit current EF6 usage** before planning any migration. Identify which features the codebase depends on:
// Common EF6-specific patterns to inventory: // - EDMX designer models (check for *.edmx files) // - ObjectContext vs DbContext usage // - Lazy loading with virtual navigation properties // - Database.SqlQuery<T>() for raw SQL // - Stored procedure mappings in model // - Spatial types (DbGeography, DbGeometry)
2. **Decide runtime vs ORM migration separately:**
| Path | When to use | |------|-------------| | Keep EF6 on .NET Framework | Legacy app with no runtime pressure | | EF6 on modern .NET | Runtime upgrade needed, ORM migration too risky | | EF6 → EF Core | Clean data layer, no EDMX, minimal stored-procedure mapping |
3. **For maintenance work** — keep EF6 stable:
- use repository + unit of work patterns to isolate data access (see [references/patterns.md](references/patterns.md))
- prefer `DbContext` over `ObjectContext` for new code
- use `AsNoTracking()` for read-only queries
- configure concurrency tokens with `[ConcurrencyCheck]` or `IsRowVersion()`
4. **For migration work** — validate each slice:
- map EF6 features to EF Core equivalents (see [references/migration.md](references/migration.md))
- migrate one bounded context at a time, not the entire data layer
- run integration tests against the real database provider, not InMemory
- verify: `dotnet ef migrations add` succeeds, queries produce equivalent results, lazy loading behavior matches expectations
5. **Do not promise EF Core features to EF6 codebases** — EF6 is stable and supported but not on the innovation path. Keep expectations realistic.
Current Upstream Notes
- The July 2026 EF Core vs EF6 comparison refresh keeps the ORM migration decision separate from runtime modernization. EF6 can remain the right ORM when EDMX, ObjectContext, or complex legacy mappings dominate the risk.
- EF Core `v10.0.10` servicing does not change EF6 guidance by itself; only move an EF6 codebase when the project has a bounded migration slice and database-backed equivalence tests.
flowchart LR
A["Audit EF6 usage"] --> B{"EDMX or complex mappings?"}
B -->|Yes| C["High migration cost — consider keeping EF6"]
B -->|No| D["Evaluate EF Core migration"]
D --> E["Migrate one context at a time"]
E --> F["Integration test against real DB"]
C --> G["Modernize runtime only"]
F --> H["Validate query equivalence"]
G --> HDeliver
- realistic EF6 maintenance or migration guidance based on actual codebase audit
- clear separation between runtime upgrade and ORM upgrade work
- bounded migration slices with concrete validation checkpoints
- reduced risk for legacy data access changes
Validate
- EF6 feature inventory is complete before migration planning starts
- migration assumptions are backed by real feature usage, not guesses
- EF6-only features (EDMX, spatial types, ObjectContext patterns) are identified early
- integration tests run against the real database provider, not mocks or InMemory
- the proposed path avoids unnecessary churn in stable data access code
References
- [references/migration.md](references/migration.md) - decision framework, migration approaches, EF6-to-EF Core feature mapping, and common pitfalls
- [references/patterns.md](references/patterns.md) - repository and unit of work patterns, query optimization, concurrency handling, auditing, and testing strategies for EF6 codebases
Stop explaining .NET to your AI. Start building. We've all been there: asking Claude to use Entity Framework, only to get EF6 patterns in a .NET 8 project. Explaining to Copilot that Blazor Server and Blazor WebAssembly aren't the same thing.
Repo: managedcode/dotnet-skills
Other skills on dotnet-skills.
- /aspnet-core
Build, debug, modernize, or review ASP.NET Core applications with correct hosting, middleware, security, configuration, logging, and deployment patterns on current .NET. USE FOR: working on ASP.NET Core apps, services, or middleware; changing auth, routing, configuration,
Open skill - /aspire
Build, upgrade, and operate Aspire 13.4.x C# or TypeScript application hosts with the current CLI, AppHost, ServiceDefaults, integrations, dashboard, testing, MCP, and deployment patterns for distributed apps. USE FOR: Aspire.AppHost.Sdk, Aspire.Hosting.*,
Open skill - /azure-functions
Build, review, or migrate Azure Functions in .NET with correct execution model, isolated worker setup, bindings, DI, and Durable Functions patterns. USE FOR: working on Azure Functions in .NET; migrating from the in-process model to the isolated worker model; adding Durable
Open skill - /blazor
Build and review Blazor applications across server, WebAssembly, web app, and hybrid scenarios with correct component design, state flow, rendering, and hosting choices. USE FOR: building interactive web UIs with C# instead of JavaScript; choosing between Server, WebAssembly, or
Open skill - /entity-framework-core
Design, tune, or review EF Core data access with proper modeling, migrations, query translation, performance, and lifetime management for modern .NET applications. USE FOR: DbContext, migrations, model configuration, EF queries, tracking, loading, performance, transactions, and
Open skill - /maui
Build, review, or migrate .NET MAUI applications across Android, iOS, macOS, and Windows with correct cross-platform UI, platform integration, and native packaging assumptions. USE FOR: working on cross-platform mobile or desktop UI in .NET MAUI; integrating device capabilities,
Open skill

