Från EF6 till EF Core: vad som ändras, vad som går sönder och hur du gör det säkert

Det är i datalagret som en modernisering av .NET går fel i tysthet. Skärmarna ser likadana ut, bygget är grönt, och en fråga som förut laddade en order med dess rader laddar nu ordern utan dem. Microsoft är tydligt: EF Core är en helt omskriven version av Entity Framework, och det finns ingen direkt uppgraderingsväg från EF6.

Den goda nyheten är att du inte behöver göra allt på en gång.

Måste du byta nu?

Inte nödvändigtvis. EF6 körs även på modern .NET: version 6.5.2, släppt i april 2026, är kompatibel med .NET 10. EF Core körs däremot bara på modern .NET, inte på .NET Framework. Det ger den säkra ordningen:

1. Flytta applikationen från .NET Framework till .NET 10 och behåll EF6.
2. Byt sedan från EF6 till EF Core, en del i taget.

Två stora ändringar i samma släpp gör det svårt att veta vad som orsakade ett problem. En i taget håller varje steg testbart. Hur du tar dig an det första steget beskriver vi i artikeln om att migrera .NET Framework till .NET 10.

Varför byta till EF Core alls, om EF6 fortsätter att fungera? För att all ny utveckling sker i EF Core, och EF6 får inga nya funktioner. I praktiken betyder det bättre prestanda, massuppdateringar och massborttagningar utan att läsa in data i minnet (ExecuteUpdate, ExecuteDelete) och verktygen som resten av .NET bygger på. Microsoft nämner en kund där en tung fråga efter bytet gav 40 gånger mindre belastning, tack vare query splitting.

Ordningen som fungerar

1. Steg 1Inventering av datalagret
2. Steg 2EF6 på .NET 10
3. Steg 3EF Core en del i taget
4. Steg 4Ta bort EF6

Steg 3 går eftersom EF6 och EF Core kan köras sida vid sida i samma applikation. Order kan flytta till EF Core medan faktureringen fortfarande körs på EF6, och varje del går till produktion för sig.

Inventeringen i steg 1 besvarar frågorna som avgör arbetsinsatsen:

• Ligger modellen i en EDMX-fil från designern, eller i kod?
• Förlitar sig koden på lazy loading?
• Hur mycket rå SQL, Entity SQL och hur många lagrade procedurer finns det?
• Vilka frågor är affärskritiska: fakturering, lager, lön?
• Finns det integrationstester mot en riktig databas?

Skillnader som ändrar beteendet utan felmeddelande

De flesta skillnader visar sig som kompileringsfel, och det är de enkla. De här kompilerar och beter sig ändå annorlunda:

I EF6	I EF Core	Vad du gör
Lazy loading fungerar med virtuella navigeringsegenskaper	Avstängt, om du inte lägger till paketet Microsoft.EntityFrameworkCore.Proxies och anropar UseLazyLoadingProxies()	Läs in relaterade data uttryckligen med Include, eller slå på proxies medvetet
Vissa C#-funktioner översätts till SQL	Inte alla; ett uttryck som inte kan översättas ger fel först vid körning	Kör varje frågeväg i tester, inte första gången i produktion
Ändringsspårning över hela grafen, ofta	Per entitet, och mer sällan	Kontrollera kod som ändrar entiteter och förlitar sig på automatisk spårning
Föräldralösa underrader behålls	Beroende rader utan förälder tas bort	Kontrollera relationer där barn kan förlora sin förälder
Data annotations valideras vid sparande	Ingen validering vid sparande	Validera i applikationen innan du sparar

Lazy loading är det du ska kontrollera först. I EF6 läser den här koden in orderraderna vid första åtkomst. I EF Core utan proxies är order.Lines helt enkelt inte inläst, och summan blir fel utan något felmeddelande:

var order = db.Orders.Single(o => o.Id == id);
// EF6 läser in raderna här. EF Core utan proxies gör det inte.
var total = order.Lines.Sum(l => l.Amount);

Uttrycklig inläsning är tydligare, och oftast snabbare:

var order = db.Orders
    .Include(o => o.Lines)
    .Single(o => o.Id == id);

Det som helt enkelt saknas

• EDMX. EF Core har ingen designer och läser inte EDMX-filer. I stället genereras modellen från den befintliga databasen och underhålls sedan i kod:

  dotnet ef dbcontext scaffold "Server=...;Database=Shop;Trusted_Connection=True;" Microsoft.EntityFrameworkCore.SqlServer

• Entity SQL och ObjectContext. Frågor i Entity SQL flyttar till LINQ eller rå SQL, och kod som når ObjectContext via IObjectContextAdapter måste skrivas om.

• Migreringshistoriken. EF Core kan inte fortsätta EF6-migreringar. Kör den sista EF6-migreringen, skapa en ny första migrering i EF Core och fortsätt därifrån. Databasen och data förblir som de är.

• Databasinitierare och automatiska migreringar. Schemaändringar går via uttryckliga migreringar.

Rå SQL fungerar fortfarande, med säkrare standardval. FromSql gör interpolerade värden till SQL-parametrar:

var orders = await db.Orders
    .FromSql($"EXECUTE dbo.GetOpenOrders {customerId}")
    .ToListAsync();

Så testar du att data inte har ändrats

”Det kompilerar” bevisar ingenting här, och Microsofts egen guide säger samma sak. Det som fungerar:

1. Jämför SQL. Logga den SQL som EF6 och EF Core skickar för de kritiska frågorna, och jämför. EF Core visar den med ToQueryString() eller LogTo.
2. Testa mot en riktig databas, inte en databas i minnet. Skillnader i inläsning och borttagning syns först med riktiga tabeller och relationer.
3. Jämför resultaten. Summor och antal från fakturering, lager eller lön, före och efter, på samma kopia av produktionsdata.
4. Släpp en del i taget, och håll koll på fel och långsamma frågor i produktion de första dagarna.

Hur lång tid det tar

Ungefärliga intervall, när applikationen redan körs på modern .NET:

• en liten modell konfigurerad i kod, med lite rå SQL: några dagar
• en typisk affärsapplikation med EDMX-modell, lazy loading och lagrade procedurer: 2 till 6 veckor
• ett stort system med hundratals entiteter, Entity SQL och utan tester: 2 till 4 månader, en del i taget, vid sidan av den vanliga utvecklingen

Själva mappningen är sällan det som tar tid. Det gör beteendeskillnaderna, och testerna som visar att de är hanterade.

När datalagret väl körs på EF Core är de vanligaste prestandaproblemen i EF Core nästa sak att kontrollera.

Så arbetar vi

ProCoding är en .NET-studio från Split i Kroatien, och datalagret är där vi lägger mycket av vår tid: prestanda i EF Core, migreringar och att ta över system som ingen vill röra. Vi börjar med en inventering av ditt datalager, föreslår ordningen och flyttar en del i taget, med tester som visar att data inte har ändrats. På egen hand, med ditt team eller som .NET-konsult i ditt team. Mer om att modernisera äldre .NET-applikationer finns på vår sida om Blazor och migrering. Första steget: Boka ett kostnadsfritt samtal på 30 minuter.

Källor

• Port from EF6 to EF Core, Microsoft Learn
• Detailed cases for porting from EF6 to EF Core, Microsoft Learn
• Port an EF6 EDMX-based model to EF Core, Microsoft Learn
• What’s new in EF6, Microsoft Learn
• Lazy loading of related data, Microsoft Learn
• Client vs. server evaluation, Microsoft Learn