here<\/a>.<\/p>\n\n\n\nAnd now on to Rider 2026.2 EAP 1 release highlights.<\/p>\n\n\n\n
Major Roslyn performance improvements with faster branch switching<\/h2>\n\n\n\n
Rider 2026.2 EAP 1 introduces a significant round of performance improvements for Roslyn integration, with a focus on one of the most painful scenarios in large solutions: switching branches.<\/p>\n\n\n\n
Branch switching is one of those everyday actions that should feel uneventful. You change branches, Rider updates the solution model, Roslyn catches up, and you keep working. But in large solutions, especially those with many projects or target frameworks, this process could become noticeably slow. In some cases, it could also cause freezes or Roslyn crashes.<\/p>\n\n\n\n
Rider 2026.2 EAP 1 addresses this with a set of targeted improvements to how Rider communicates project model changes to Roslyn. We\u2019ve reduced the number of requests, added batching, cut down the amount of transferred data, and fixed a hang caused by passing non-existent files to Roslyn.<\/p>\n\n\n\n
The result is a much smoother experience when switching branches, especially in large or complex solutions. In typical large-project scenarios, branch switching is now 2\u20133x faster<\/strong>. <\/p>\n\n\n\nIn some of the worst cases we tested, the improvement is much more dramatic. One BenchmarkDotNet scenario (~25 projects included) improved from 8 minutes to 5 seconds<\/strong>, making branch switching in that case nearly 100x faster<\/strong>.<\/p>\n\n\n\nThis work also fixes a number of Roslyn-related issues around project references, .editorconfig<\/code> handling, available analyzers, and target framework changes.<\/p>\n\n\n\nGame dev goodness<\/h2>\n\n\n\nUnity <\/h3>\n\n\n\n
For Unity developers, we\u2019ve significantly reworked how Rider handles asmdef references. This should improve how Rider understands Unity projects that use assembly definition files and make project model updates more reliable.<\/p>\n\n\n\n
Godot <\/h3>\n\n\n\n
Rider 2026.2 EAP 1 brings a set of fixes and quality improvements for GDScript support, addressing several issues that could make the editing experience less smooth than expected.<\/p>\n\n\n\n
Spellchecking is now available in GDScript files, helping you catch typos directly in the editor. <\/p>\n\n\n\n
Azure Functions support is moving into Rider<\/h2>\n\n\n\n
We\u2019re migrating Azure Functions features for local development from the separate Azure Toolkit plugin into JetBrains Rider itself.<\/p>\n\n\n\n
This means you\u2019ll be able to develop Azure Functions locally without installing any additional plugins. Most of the existing functionality has already been moved, including project and trigger creation, running, debugging, Azurite integration, and more. A few smaller features are still pending and will be added in upcoming EAP builds.<\/p>\n\n\n\n
We\u2019ve also added the ability to create an Azure Functions trigger from the project creation dialog. In addition, Azure Functions projects can now be debugged inside a Docker container. Previously, this Docker debugging workflow was available only for regular .NET projects.<\/p>\n\n\n\n
Aspire improvements<\/h2>\n\n\n\n
Rider 2026.2 EAP 1 also includes several updates for Aspire.<\/p>\n\n\n\n
We now support file-based AppHosts for Aspire projects. Dev certificate validation for Aspire apps has also been improved.<\/p>\n\n\n\n
There are also improvements to how AppHost.cs is displayed in the editor. Rider now shows the status of each resource, such as whether it\u2019s running or stopped, and lets you execute resource commands directly from the gutter.<\/p>\n\n\n\n
\n\n\n\nFor the full list of changes included in this build, please see our release notes.<\/p>\n\n\n\n
We encourage you to download the EAP build, give these new features a try, and share your feedback. The Early Access Program is a collaborative effort, and your input plays a vital role in making Rider the best it can be.<\/p>\n\n\n