What Changed in IDEs: From Visual Studio 2022 to 2026, and Rider and VS Code in 2025–2026

Version note: The commands in this post were run with .NET 10 SDK (Software Development Kit) 10.0.402. Visual Studio 2026 and Rider were not run on this machine (macOS); version information is compiled from the Microsoft Learn release notes, JetBrains' .NET Tools blog and the Visual Studio Code (VS Code) update notes as of November 8, 2026. This is a living post: .NET 11 is expected on November 10, 2026, and the IDE (Integrated Development Environment) support section must be updated at publication time.

Guess First

The Bookstore team wants to open a branch and try .NET 11 as soon as it ships. One developer updates Visual Studio 2026, another uses Rider, a third works in VS Code. In the same repo, main stays on .NET 10 while the trial branch moves to .NET 11. Which file, if you leave it out of the repo, lets an IDE update silently move main's build to the .NET 11 SDK? And what does dotnet say when that file asks for an SDK that isn't on the machine?

In the last post of the series we look back: what changed from Visual Studio 2022 to 2026, what the 18.x line brought in a year, where Rider and VS Code went in 2025 and 2026, and an IDE-side checklist for moving to .NET 11.

Visual Studio 2026 GA: What Changed

Visual Studio 2026 became generally available with 18.0 on November 11, 2025, the same day as .NET 10. The headlines in the release notes:

UI (User Interface): a move to the Fluent UI design system, 11 tinted themes, an Editor Appearance setting that sets the editor's look separately from the IDE theme, and redrawn icons. The new settings experience that replaces Tools > Options also started with this release; in 18.11 Fonts and Colors moved into it too.

Performance: Microsoft writes that Visual Studio 2026 with .NET 10 starts up to 30 percent faster with F5 than Visual Studio 2022 with .NET 9. This is a vendor measurement and there is no guarantee you'll see the same difference in your own solution; if you want to measure, install both versions side by side on the same solution and compare with your own scenario.

Model: monthly feature updates, the IDE decoupled from the build tools, and an annual release that arrives every November with the new .NET and updates the previous installation in place (detailed in the second post). The Visual Studio 2026 LTSC (Long-Term Servicing Channel) for Professional, Enterprise and Build Tools arrives in November 2026.

Extensions: according to Microsoft's October 2025 post on extension compatibility, extensions written for Visual Studio 2022 are expected to work in 2026 without updates; Visual Studio only looks at the lower bound of the version range an extension targets. Most 2022 extensions can be carried over during installation, but as we said in the eighth post, "works" is not the same as "maintained".

The 18.x Line: Eleven Feature Updates in a Year

From 18.0 to 18.11 a feature update arrived every month. The table below summarizes what matters to a .NET + Angular developer, with the dates from the release notes:

A small but valuable debugger change is the operand highlighting in 18.10: in C# if statements whose conditions are combined with && or ||, red and green highlighting shows which operand decided the result. "Why didn't this if go in" gets answered in a four-operand condition without typing each part into the Watch window.

On the Insiders channel, 18.12 (late October 2026) shows the horizon: a File System view in Solution Explorer that shows the repo as it is on disk, Close Tabs to the Right, a side-by-side diff for string assertions in Test Explorer, vertical guides for max_line_length and rulers in .editorconfig, resolving Git conflicts with Copilot, and the new Copilot chat as the default. These are in Insiders; follow the release notes for when they reach Stable.

Rider from 2025.3 to 2026.2

Rider's three major releases a year followed this line over the same period. 2025.3 (November 2025) brought, in the words of JetBrains' release post title, "day-one support for .NET 10 and C# 14, a new default UI and faster startup". 2026.1 (March 30, 2026) added one-click agent installation through the ACP (Agent Client Protocol) Registry, Git worktrees, opening and running single-file C# programs without a project file, the NuGet Package Manager Console (preview) and an ASM (Assembly) Viewer that shows JIT (Just-In-Time), ReadyToRun and NativeAOT output. 2026.2 (July 22, 2026) is detailed in the seventh post: faster debugger launch and branch switching, WPF (Windows Presentation Foundation) Hot Reload, built-in Copilot and .NET agent skills.

2026.3 has been in the Early Access Program since September 7, 2026: bracket colorization (off by default), data breakpoints set with a right-click in the editor and code completion filters are in the first EAP (Early Access Program) build. For C# 15 the picture is this: Microsoft announced C# 15's union keyword with .NET 11 Preview 2 in April 2026; Rider 2026.2's release notes have no full support for C# 15, and at the time of writing the final 2026.3 hasn't shipped. If you'll use Rider with .NET 11, wait for the 2026.3 release notes.

VS Code: From Monthly to Weekly, from Editor to Agent Workspace

VS Code's most visible change in 2026 is its rhythm: with 1.111 (March 9, 2026) the Stable channel moved to weekly releases; the monthly releases of 2025 were replaced by weekly ones, reaching 1.145 on November 4, 2026. On the content side the direction is clear: the integrated browser in 1.109, agent permission levels and Autopilot (preview) in 1.111, the Agents window reaching Stable in 1.120 (May 13, 2026), the agent host in 1.130, agent sessions inside Dev Containers in 1.140, and mixing different harnesses in the same session plus cron automations in 1.145. On the C# side, .NET 10 support continues with C# Dev Kit; JetBrains adding a debugger to its ReSharper extension for VS Code-compatible editors in 2026.2 also brought a second C# engine to the editor world.

The practical consequence of the weekly rhythm: in VS Code, the "which version did this feature arrive in" information can go four versions stale within a month. If you want to pin versions on a team, think about VS Code's automatic update (update.mode) and extension versions together.

IDE Support for .NET 11 and C# 15

According to the .NET release index, as of November 8, 2026 the latest .NET 11 build is 11.0.0-rc.3 from October 25, 2026; its support phase is "go-live", meaning usable in production but not yet GA (General Availability). .NET 11 is an STS (Standard Term Support) release; .NET 10 is LTS (Long-Term Support). Microsoft announced it will release .NET 11 at .NET Conf 2026, which starts on November 10, 2026. At the time of writing, C# 15 features (for example union) can only be tried with a preview SDK and <LangVersion>preview</LangVersion>; since this series is based on .NET 10, we don't give C# 15 code.

IDE support could not be verified at this date: the Visual Studio Stable and Insiders release notes (18.11 and 18.12 Insiders) have no line about .NET 11 support, Rider 2026.3 is still in EAP, and C# Dev Kit uses the installed SDK. At publication time, check three sources: the Visual Studio release notes, the Rider 2026.3 release post and the "supported IDEs" section of the .NET 11 release notes.

Migration Checklist: Side-by-Side Installs and global.json

The answer to Guess First is global.json. When an IDE update installs a new SDK and the repo has no global.json, dotnet picks the newest SDK on the machine. The SDKs on this machine:

$ dotnet --list-sdks
8.0.419 [/usr/local/share/dotnet/sdk]
10.0.103 [/usr/local/share/dotnet/sdk]
10.0.402 [/usr/local/share/dotnet/sdk]

The file that keeps main on .NET 10's 400 feature band:

{
  "sdk": {
    "version": "10.0.400",
    "rollForward": "latestPatch"
  }
}

$ dotnet --version
10.0.402

latestPatch moves up to the highest patch within the 10.0.400 band (10.0.402) but never to 10.0.500 or 11.0. When we switched global.json to .NET 11 on the trial branch while that SDK isn't on the machine:

{
  "sdk": {
    "version": "11.0.100",
    "rollForward": "latestFeature"
  }
}

$ dotnet --version
The command could not be loaded, possibly because:
  * You intended to execute a .NET application:
      The application '--version' does not exist or is not a managed .dll or .exe.
  * You intended to execute a .NET SDK command:
      A compatible .NET SDK was not found.

Requested SDK version: 11.0.100
global.json file: ./global.json

Install the [11.0.100] .NET SDK or update [./global.json] to match an installed SDK.
$ echo $?
155

The error is clear and early: the build doesn't silently run with the wrong SDK; it doesn't run at all. IDEs respect the same file; C# Dev Kit's "A compatible .NET SDK was not found" warning that we saw in the sixth post is exactly this situation. When trying pre-releases such as an RC (Release Candidate), you need to add "allowPrerelease": true to global.json. The full checklist:

• Verify IDE support: the Visual Studio 2026 version that supports .NET 11, Rider 2026.3, the current C# Dev Kit; look for the .NET 11 and C# 15 lines in the release notes.
• Install the SDK side by side: .NET SDKs live together on the same machine; old branches stay on .NET 10 through global.json.
• Update Visual Studio in a controlled way: since the annual release will be an in-place update, if you have a critical project consider LTSC on Professional and Enterprise, or trying the update on a second machine.
• Add the new SDK to CI (Continuous Integration) agents and install the version that matches global.json; keep the SDK in CI and on developer machines in the same band.
• Try multi-targeting first: build with <TargetFrameworks>net10.0;net11.0</TargetFrameworks> and run the tests on both targets.
• Watch analyzer and code style differences: a new SDK can bring new analyzer rules; the dotnet format --verify-no-changes and build warnings from the fourth post show the difference in CI.
• Move the Dev Container image and Docker base images to the .NET 11 tag too; the digest pinning from the sixth post applies here as well.

In Production

Manage the IDE version and the SDK version separately. Since Visual Studio is now decoupled from the build tools, updating the IDE every month doesn't have to change the project's SDK; global.json is what makes that possible.

Verify vendor numbers with your own measurements. Numbers such as "up to 30 percent faster startup" or "2.8 seconds faster debugger" are the vendor's own scenarios; if they are going to justify a big decision (switching IDEs, buying licenses), measure in your own solution.

Keep version information in one place. Keep which IDE version, which SDK and which extension versions the team uses on a single page; as we saw throughout this series, everything changes monthly, and weekly in VS Code.

Common Pitfalls

Not adding a global.json. The new SDK that comes with an IDE update changes the whole team's build without anyone noticing.

Choosing the wrong rollForward. latestMajor moves up to the next major version; if you want to keep main fixed, use latestPatch or latestFeature.

Forgetting allowPrerelease with an RC SDK. Even if a pre-release SDK is installed, it isn't selected unless global.json allows it.

Changing the TargetFramework without verifying IDE support. Even if the compiler knows the new target, the IDE's language service may not recognize new language features; you see red squiggles in the editor and a green build.

Making a vendor performance claim the sole reason for a decision. Saying "the new version is faster" without measuring can turn into disappointment on the first big solution.

A Small Experiment

★☆☆ Add a global.json like the one above to your repo, note the output of dotnet --version, and compare the result with rollForward set to latestPatch, latestFeature and latestMajor.

★★☆ Install the .NET 11 SDK (RC or GA) side by side, change global.json and the TargetFramework on a separate branch, open the project in the three IDEs (if installed) and note which one recognizes the new version without trouble.

★★★ Turn this post's checklist into an "IDE and SDK version policy" page for your team: which IDE version, which channel, which SDK band, how extensions are pinned, and when and by whom a new version is tried.

The series ends here. From choosing an IDE to shortcuts, from refactoring to debug configurations, from extension security to AI (Artificial Intelligence) assistants, we put the three tools side by side. From here, the Debugging and Problem Solving series continues with the debugger itself, and the upcoming Terminal and Command Line and API (Application Programming Interface) Tools series with the tools that live outside the IDE.