|
| 1 | +--- |
| 2 | +title: Breaking changes in EF Core 11 (EF11) - EF Core |
| 3 | +description: List of breaking changes introduced in Entity Framework Core 11 (EF11) |
| 4 | +author: AndriySvyryd |
| 5 | +ms.date: 07/13/2026 |
| 6 | +uid: core/what-is-new/ef-core-11.0/breaking-changes |
| 7 | +--- |
| 8 | + |
| 9 | +# Breaking changes in EF Core 11 (EF11) |
| 10 | + |
| 11 | +This page documents API and behavior changes that have the potential to break existing applications updating from EF Core 10 to EF Core 11. Make sure to review earlier breaking changes if updating from an earlier version of EF Core: |
| 12 | + |
| 13 | +- [Breaking changes in EF Core 10](xref:core/what-is-new/ef-core-10.0/breaking-changes) |
| 14 | +- [Breaking changes in EF Core 9](xref:core/what-is-new/ef-core-9.0/breaking-changes) |
| 15 | +- [Breaking changes in EF Core 8](xref:core/what-is-new/ef-core-8.0/breaking-changes) |
| 16 | +- [Breaking changes in EF Core 7](xref:core/what-is-new/ef-core-7.0/breaking-changes) |
| 17 | +- [Breaking changes in EF Core 6](xref:core/what-is-new/ef-core-6.0/breaking-changes) |
| 18 | + |
| 19 | +## Summary |
| 20 | + |
| 21 | +| **Breaking change** | **Impact** | |
| 22 | +|:----------------------------------------------------------------------------------------------------------|------------| |
| 23 | +| [Cosmos: `__jObject` shadow property removed; JObject no longer used for serialization](#jObject-removed) | High | |
| 24 | +| [Cosmos: Unmapped properties are no longer preserved](#unmapped-properties) | High | |
| 25 | +| [Cosmos: Floating-point values are now truncated when materializing to fixed-point types](#truncation) | Low | |
| 26 | + |
| 27 | +## High-impact changes |
| 28 | + |
| 29 | +<a name="jObject-removed"></a> |
| 30 | + |
| 31 | +### Cosmos: `__jObject` shadow property removed; JObject no longer used for serialization |
| 32 | + |
| 33 | +[Tracking Issue #5421](https://github.com/dotnet/EntityFramework.Docs/issues/5421) |
| 34 | + |
| 35 | +#### Old behavior |
| 36 | + |
| 37 | +Previously, the Azure Cosmos DB provider added a shadow property named `"__jObject"` of type `JObject` (from `Newtonsoft.Json`) to every entity type. This property contained the raw JSON document as received from and sent to Cosmos DB, allowing users to access unmapped or raw data: |
| 38 | + |
| 39 | +```csharp |
| 40 | +var order = await context.Orders.FirstAsync(); |
| 41 | +var rawJson = context.Entry(order).Property<JObject>("__jObject").CurrentValue; |
| 42 | +var billingAddress = rawJson["BillingAddress"]?.Value<string>(); |
| 43 | +``` |
| 44 | + |
| 45 | +EF Core used `Newtonsoft.Json` (via `JObject`) internally for document serialization and deserialization. |
| 46 | + |
| 47 | +#### New behavior |
| 48 | + |
| 49 | +Starting with EF Core 11, the `__jObject` shadow property no longer exists. EF Core now uses `System.Text.Json` (`Utf8JsonReader`/`Utf8JsonWriter`) for document serialization and deserialization, and no longer relies on `Newtonsoft.Json`. |
| 50 | + |
| 51 | +Accessing the `"__jObject"` property will throw an `InvalidOperationException`. |
| 52 | + |
| 53 | +#### Why |
| 54 | + |
| 55 | +The `JObject`-based approach required a dependency on `Newtonsoft.Json` and limited performance improvements. Switching to `System.Text.Json` aligns EF Core Cosmos with the rest of the .NET ecosystem and enables significant performance gains. |
| 56 | + |
| 57 | +#### Mitigations |
| 58 | + |
| 59 | +To access the raw JSON document, use the `CosmosClient` directly instead of relying on `__jObject`: |
| 60 | + |
| 61 | +```csharp |
| 62 | +var cosmosClient = context.Database.GetCosmosClient(); |
| 63 | +var container = cosmosClient.GetContainer("myDatabase", "myContainer"); |
| 64 | +var response = await container.ReadItemAsync<JsonElement>("1", new PartitionKey("1")); |
| 65 | +var billingAddress = response.Resource.GetProperty("BillingAddress").GetString(); |
| 66 | +``` |
| 67 | + |
| 68 | +For more information, see [Working with Unstructured Data in Azure Cosmos DB](xref:core/providers/cosmos/unstructured-data). |
| 69 | + |
| 70 | +<a name="unmapped-properties"></a> |
| 71 | + |
| 72 | +### Cosmos: Unmapped properties are no longer preserved |
| 73 | + |
| 74 | +[Tracking Issue #5421](https://github.com/dotnet/EntityFramework.Docs/issues/5421) |
| 75 | + |
| 76 | +#### Old behavior |
| 77 | + |
| 78 | +Previously, when EF Core read a Cosmos DB document that contained properties not mapped in the EF model, those extra properties were preserved in the `__jObject` shadow property and written back to the database on the next `SaveChanges`. This meant unmapped data in documents was transparently round-tripped. |
| 79 | + |
| 80 | +#### New behavior |
| 81 | + |
| 82 | +Starting with EF Core 11, unmapped properties in a Cosmos DB document are ignored when reading. Any extra JSON properties that are not part of the EF model will be lost if the entity is subsequently saved. |
| 83 | + |
| 84 | +#### Why |
| 85 | + |
| 86 | +Because `__jObject` has been removed (see above), there is no mechanism to preserve unmapped properties. EF Core 11 uses a lean JSON reader that only processes the properties it knows about. |
| 87 | + |
| 88 | +#### Mitigations |
| 89 | + |
| 90 | +If your application relies on preserving unmapped data, consider one of the following options: |
| 91 | + |
| 92 | +- **Use `CosmosClient` directly** for documents where you need full control over the JSON shape. |
| 93 | +- **Map all relevant properties** explicitly in your EF model, even if they are not used by application logic. |
| 94 | +- **Use a JSON column or an untyped dictionary property** to capture extra data, if that pattern fits your model. |
| 95 | + |
| 96 | +## Low-impact changes |
| 97 | + |
| 98 | +<a name="truncation"></a> |
| 99 | + |
| 100 | +### Cosmos: Floating-point values are now truncated when materializing to fixed-point types |
| 101 | + |
| 102 | +[Tracking Issue #38138](https://github.com/dotnet/efcore/issues/38138) |
| 103 | + |
| 104 | +#### Old behavior |
| 105 | + |
| 106 | +Previously, when a query projection returned a floating-point value (e.g., the result of a numeric expression such as `3 / 4` returned by Cosmos as `0.75`) and the target property was a fixed-point type (`int`, `long`, `decimal`, etc.), EF Core would **round** the value. This meant `0.75` would materialize as `1`. |
| 107 | + |
| 108 | +#### New behavior |
| 109 | + |
| 110 | +Starting with EF Core 11, such values are **truncated** instead of rounded. `0.75` now materializes as `0`, matching standard .NET integer truncation behavior (`(int)0.75 == 0`). |
| 111 | + |
| 112 | +#### Why |
| 113 | + |
| 114 | +Truncation is the standard .NET behavior for explicit numeric conversions and is consistent with how other providers behave. The previous rounding behavior was a bug. |
| 115 | + |
| 116 | +#### Mitigations |
| 117 | + |
| 118 | +If you relied on the previous rounding behavior, apply explicit rounding in your queries using `Math.Round`: |
| 119 | + |
| 120 | +```csharp |
| 121 | +var result = await context.Products |
| 122 | + .Select(p => (int)Math.Round((double)(p.Int / (p.Int + 1)))) |
| 123 | + .SingleAsync(); |
| 124 | +``` |
0 commit comments