| [project.json not supported in `dotnet restore`](sdk/10.0/dotnet-restore-project-json-unsupported.md) | Source incompatible | Preview 7 |

title: "Breaking change - project.json is no longer supported in dotnet restore"

description: "Learn about the breaking change in .NET 10 where dotnet restore no longer supports project.json based projects."

ms.date: 08/16/2025

ai-usage: ai-assisted

ms.custom: https://github.com/dotnet/docs/issues/47968

Starting with .NET 10, the [`dotnet restore` command](../../../tools/dotnet-restore.md) no longer supports `project.json` based projects. Such projects are ignored during the restore operation.

.NET 10 Preview 7

The `dotnet restore` command restored dependencies for `project.json` based projects.

The `dotnet restore` command ignores `project.json` based projects and no longer restores their dependencies.

This change can affect [source compatibility](../../categories.md#source-compatibility).

The `project.json` format was originally available only in .NET Core previews (through Preview 2 of .NET Core 1.0) and was completely replaced by PackageReference in 2017. The format has been marked as deprecated since 2017.

When the `project.json` format was replaced, users migrated these projects using the [`dotnet migrate`](../../../tools/dotnet-migrate.md) command, but that command was removed from the CLI in the .NET Core 3.0 SDK.

The removal of `project.json` support completes this transition and allows the .NET team to focus on delivering a better experience for PackageReference-based projects.

Migrate your `project.json` projects to use PackageReference format instead.

If you have .NET Core based `project.json` projects, you can use older versions of the .NET SDK that still include the [`dotnet migrate` command](../../../tools/dotnet-migrate.md) to convert them to the modern project format.

For more information about migrating from `project.json`, see [Migrating from project.json to .csproj](/nuget/archive/project-json#migrate-projectjson-to-packagereference).

None.

- name: project.json not supported in `dotnet restore`

href: sdk/10.0/dotnet-restore-project-json-unsupported.md

ms.date: 08/15/2025

The same syntax that [declares](classes.md#declaring-classes) and [instantiates](classes.md#creating-objects) classes or structs can be used with records. Just substitute the `class` keyword with the `record`, or use `record struct` instead of `struct`. Likewise, record classes support the same syntax for expressing inheritance relationships. Records differ from classes in the following ways:

In the preceding examples, all properties are independent. None of the properties are computed from other property values. A `with` expression first copies the existing record instance, then modifies any properties or fields specified in the `with` expression. Computed properties in `record` types should be computed on access, not initialized when the instance is created. Otherwise, a property could return the computed value based on the original instance, not the modified copy. If you must initialize a computed property rather than compute on access, you should consider a [`class`](./classes.md) instead of a record.

ms.date: 08/15/2025

You ensure correctness on computed properties by computing the value on access, as shown in the following declaration:

:::code language="csharp" source="snippets/shared/RecordType.cs" id="WitherComputed":::

The preceding record type computes the `Distance` when accessed, as shown in the following example:

:::code language="csharp" source="snippets/shared/RecordType.cs" id="WitherComputedUsage":::

Contrast that with the following declaration, where the `Distance` property is computed and cached as part of the initialization of a new instance:

:::code language="csharp" source="snippets/shared/RecordType.cs" id="WitherInit":::

Because `Distance` is computed as part of initialization, the value is computed and cached before the `with` expression changes the value of `Y` in the copy. The result is that the distance is incorrect:

:::code language="csharp" source="snippets/shared/RecordType.cs" id="WitherInitUsage":::

The `Distance` computation isn't expensive to compute on each access. However, some computed properties might require access to more data or more extensive computation. In those cases, instead of a record, use a `class` type and compute the cached value when one of the components changes value.

Console.WriteLine("=================================================");

ComputedWither.ExampleUsage.Example();

public record Person([property: JsonPropertyName("firstName")] string FirstName,

}

;

namespace ComputedWither

{

// <WitherComputed>

public record Point(int X, int Y)

{

public double Distance => Math.Sqrt(X * X + Y * Y);

}

// </WitherComputed>

// <WitherInit>

public record PointInit(int X, int Y)

{

public double Distance { get; } = Math.Sqrt(X * X + Y * Y);

}

// </WitherInit>

public static class ExampleUsage

{

public static void Example()

{

// <WitherComputedUsage>

Point p1 = new Point(3, 4);

Console.WriteLine($"Original point: {p1}");

p1 = p1 with { Y = 8 };

Console.WriteLine($"Modified point: {p1}");

// Output:

// Original point: Point { X = 3, Y = 4, Distance = 5 }

// Modified point: Point { X = 3, Y = 8, Distance = 8.54400374531753 }

// </WitherComputedUsage>

// <WitherInitUsage>

PointInit pt1 = new PointInit(3, 4);

Console.WriteLine($"Original point: {pt1}");

pt1 = pt1 with { Y = 8 };

Console.WriteLine($"Incorrect Modified point: {pt1}");

// Output:

// Original point: PointInit { X = 3, Y = 4, Distance = 5 }

// Modified point: PointInit { X = 3, Y = 8, Distance = 5 }

// </WitherInitUsage>

}

}

}

If the `using static` directive is applied within the context of a namespace (either file-scoped or nested in a `namespace` block, it is not necessary to fully qualify the type.

Exception filters with the `when` keyword provide several advantages over traditional exception handling approaches, including better debugging support and performance benefits. For a detailed explanation of how exception filters preserve the call stack and improve debugging, see [Exception filters vs. traditional exception handling](../statements/exception-handling-statements.md#exception-filters-vs-traditional-exception-handling).

title: "The with expression - create new objects that are modified copies of existing objects"

ms.date: 08/15/2025

When a member is a reference type, only the reference to a member instance is copied when an operand is copied. Both the copy and original operand have access to the same reference-type instance. The following example demonstrates that behavior:

Exception filters provide significant advantages over traditional exception handling approaches. The key difference is **when** the exception handling logic is evaluated:

- **Exception filters (`when`)**: The filter expression is evaluated *before* the stack is unwound. This means the original call stack and all local variables remain intact during filter evaluation.

- **Traditional `catch` blocks**: The catch block executes *after* the stack is unwound, potentially losing valuable debugging information.

Here's a comparison showing the difference:

:::code language="csharp" source="snippets/exception-handling-statements/WhenFilterExamples.cs" id="ExceptionFilterVsIfElse":::

- **Better debugging experience**: Since the stack isn't unwound until a filter matches, debuggers can show the original point of failure with all local variables intact.

- **Performance benefits**: If no filter matches, the exception continues propagating without the overhead of stack unwinding and restoration.

- **Cleaner code**: Multiple filters can handle different conditions of the same exception type without requiring nested if-else statements.

- **Logging and diagnostics**: You can examine and log exception details before deciding whether to handle the exception:

:::code language="csharp" source="snippets/exception-handling-statements/WhenFilterExamples.cs" id="DebuggingAdvantageExample":::

Use exception filters when you need to:

- Handle exceptions based on specific conditions or properties.

- Preserve the original call stack for debugging.

- Log or examine exceptions before deciding whether to handle them.

- Handle the same exception type differently based on context.

:::code language="csharp" source="snippets/exception-handling-statements/WhenFilterExamples.cs" id="MultipleConditionsExample":::

Exception filters preserve the original `ex.StackTrace` property. If a `catch` clause can't process the exception and re-throws, the original stack information is lost. The `when` filter doesn't unwind the stack, so if a `when` filter is `false`, the original stack trace isn't changed.

The exception filter approach is valuable in applications where preserving debugging information is crucial for diagnosing issues.