Our release for ReSharper and Rider 2025.1 is just around the corner, and we have lots of exciting features shipping for the current and next version of C#! This will be a really long post (blame our awesome devs!), so make sure to use the table of contents on the right. Oh, and of course\u2026<\/p>\n\n\n
For many of the inspections and quick fixes discussed in this post, we recommend using either find in scope<\/em><\/a> or fix in scope<\/em><\/a> to effectively use them in your codebases. Now, let’s talk about new features!<\/p>\n\n\n\n\n\n\n\n In ReSharper and Rider 2025.1, we enhanced support for structured and high-performance logging<\/a> using the Our .NET IDEs offer a wide range of suggestions and context actions for working with C# string literals, interpolated strings, However, some conversion directions were still missing. For example, while it’s been easy to convert a concatenated string like Implicit usings<\/em><\/a> simplify your project by automatically including a set of commonly used namespaces, reducing clutter and improving readability. However, there might be scenarios where you prefer explicit control over your namespace imports \u2014 for example, to ensure clarity about exactly which namespaces are available or to improve compatibility with certain tooling and team conventions.<\/p>\n\n\n\n ReSharper and Rider 2025.1 introduce a convenient action that allows you to easily toggle implicit usings<\/em> on or off for your project. When enabling implicit usings<\/em>, ReSharper automatically removes redundant explicit In the previous release, we introduced support for multiline to-do comments, where subsequent lines were considered part of the same item based on their indentation. In the 2025.1 release, we’ve enhanced this feature by making indentation optional. Now, lines following a to-do comment are automatically treated as part of the same item, even without indentation, making multiline comments more intuitive and seamless. However, if indentation is used, it will be strictly enforced:<\/p>\n\n\n\n Language injection made its debut in ReSharper around 10 years ago with support for regular expressions<\/a>. Since then, it has been brought to Rider, expanded to other languages<\/a>, and updated to work with new language and runtime features<\/a>.<\/p>\n\n\n\n Previously, the In the previous two versions, we introduced inspections for more specific scenarios of code duplication \u2014 common code in Our first inspection detects duplicated statements that appear both within conditional branches of Another inspection detects redundant arms in switch expressions \u2014 specifically, arms that return the same value as the default one. Removing these redundancies simplifies your code and improves readability:<\/p>\n\n\n\n The last inspection detects when multiple When working with asynchronous methods, it’s common to pass a ReSharper and Rider 2025.1 introduce a new inspection that detects when a broader-scoped cancellation token is mistakenly used instead of a more appropriate local token available within a local function or lambda. You can choose from two corresponding quick-fixes to either a) replace the mistakenly used token with the correct local token, or b) link both tokens into one using Primary constructors in C# 12 greatly simplify constructor dependency injection patterns. You only need to mention a dependency once in the constructor parameter list, and it automatically becomes available across all instance members of the class without the need to define and assign a field explicitly.<\/p>\n\n\n\n In ReSharper and Rider 2025.1, we introduce a new The transform parameters refactoring<\/a> makes it easy to change a method’s signature by modifying its parameters \u2014 for example, removing With ReSharper and Rider 2025.1, we reworked the refactoring to support modern language features (including tuple types, record classes, and primary constructors), treat tuple elements as multiple return values, transform One of the very subtle features in ReSharper and Rider is the highlighting of matching code elements<\/a> (for instance, check out Matching of control flow keywords<\/em>). From 2025.1, we will help you to visually identify members that extend the base class or implement some concrete interface type. Just place the caret over the type name in the base types clause:<\/p>\n\n\n\n Our built-in formatter helps you to align your code with your preferred code formatting style settings. It can be invoked manually, through an \u201con-save\u201d action<\/a>, or before committing changes<\/a>. Sometimes, though, you may want more control without triggering widespread formatting. A new context action lets you apply chop formatting to various C# constructs directly without needing to make a selection:<\/p>\n\n\n\n When writing code assertions using APIs like Our new 2025.1 code inspection detects and warns you about such cases automatically:<\/p>\n\n\n\n A common mistake when working with .NET’s Starting with our 2025.1 IDEs, incorrect usage patterns of Tuple types allow you to use both explicit and generic component names. Sometimes, it is overlooked that a component can be referenced by its explicit name, e.g., The In 2025.1, we are adding a new inspection Use Another new feature in C# 14 now allows using the ReSharper and Rider identify places where generic types in In recent years, the BCL and many other libraries have extensively adopted Structured Logging Support<\/h2>\n\n\n\n
Microsoft.Extensions.Logging<\/code> APIs. Similar to how formatting arguments are highlighted in string.Format<\/code> using the {0}<\/code> syntax, we now highlight the corresponding type arguments in the Logger.Define<\/code> and LoggerMessageAttribute<\/code> API. Additionally, missing type arguments are now reported with diagnostics to catch issues early, along with quick-fixes and context actions to add or remove them as needed:<\/p>\n\n\n\nString Construction Context Actions<\/b><\/h2>\n\n\n\n
string.Format<\/code>, and StringBuilder<\/code> constructs. You can convert nearly any string-related expression into various other forms to enhance readability or to better parameterize string construction.<\/p>\n\n\n\n\"Id = \" + someId<\/code> into either an interpolated string $\"Id = {someId}\"<\/code> or a format string string.Format(\"Id = {0}\", someId)<\/code>, there hasn’t been a way to reverse this \u2014 i.e., to convert interpolated or formatted strings back into concatenation. In certain scenarios, such a transformation can actually result in more concise or readable code:<\/p>\n\n\n\nImplicit Usings Refactoring<\/h2>\n\n\n\n
using<\/code> directives from your source files, streamlining your codebase. Conversely, disabling implicit usings<\/em> will explicitly add the necessary namespaces into your files, ensuring your code remains compilable and readable without any manual adjustments:<\/p>\n\n\n\nImproved Multiline To-Do Comments<\/b><\/h2>\n\n\n\n
Language Injection in Return Values<\/b><\/h2>\n\n\n\n
LanguageInjection<\/code> attribute (from JetBrains.Annotations<\/code><\/a>) could only be applied to parameters, fields, and properties. Now you can annotate methods to specify that their returned strings represent an embedded code of another language:<\/p>\n\n\n\nRedundant Duplicated Code<\/h2>\n\n\n\n
if<\/code> and switch<\/code> statements<\/a> and duplicated switch<\/code> section bodies<\/a>. In this 2025.1 release, we deliver three new inspections to help you eliminate unintentional duplications and improve readability and maintainability in your codebase.<\/p>\n\n\n\nif<\/code> and switch<\/code> statements ending with jump statements and again immediately afterward:<\/p>\n\n\n\nif<\/code> branches execute identical code and provides a handy quick-fix to merge them:<\/p>\n\n\n\nMisuse of CancellationToken<\/h2>\n\n\n\n
CancellationToken<\/code> through parameters of local functions or lambda expressions. Accidentally using a method-level token instead of a more specific, locally scoped one can lead to unintended behavior, such as tasks not being canceled when expected.<\/p>\n\n\n\nCancellationTokenSource.CreateLinkedTokenSource<\/code>:<\/p>\n\n\n\nInjection Postfix Template<\/b><\/h2>\n\n\n\n
inject<\/code> postfix template available for type names. When you realize you need to add a dependency on IService<\/code>, select it from the completion list, append .inject<\/code>, and hit your completion key:<\/p>\n\n\n\nTransform Parameters Refactoring<\/h2>\n\n\n\n
out<\/code> parameters, wrapping them in a tuple or a new class, and more \u2014 while automatically updating all usages of the method across your solution.<\/p>\n\n\n\nref<\/code> parameters into both input and output values, and handle lots of deconstruction usages. Bring up the dialog, select the parameters you want to transform, and choose your desired target types:<\/p>\n\n\n\nContext Highlighters for Extended Types<\/b><\/h2>\n\n\n\n
Chop Formatting Context Action<\/b><\/h2>\n\n\n\n
Modification in Debug.Assert<\/b><\/h2>\n\n\n\n
Debug.Assert<\/code>, it’s easy to forget that these calls are stripped out in RELEASE<\/code> builds. This is because methods marked with attributes like [Conditional(\"DEBUG\")]<\/code> are only compiled when the DEBUG<\/code> symbol is defined in the project. As a result, if the assertion condition includes side effects \u2014 such as assignments or collection mutations \u2014 those side effects will not<\/em> occur in RELEASE<\/code> builds. These conditional side effects are hard to spot and reason about, and they can lead to subtle bugs or unexpected behavior.<\/p>\n\n\n\nInexact Stream Reads<\/b><\/h2>\n\n\n\n
Stream<\/code> class is misusing the Read<\/code> and ReadAsync<\/code> methods. These methods accept a buffer (an array or a Span<byte><\/code>) and are often assumed to fill it completely <\/em>\u2014 but they are not guaranteed to do so. Crucially, Stream<\/code> implementations are allowed to return partial data and will report the actual number of bytes read, which may be less than the buffer size. That’s why it’s essential to handle the return value from Read<\/code> and ReadAsync<\/code> properly and continue reading until the desired amount of data is received.<\/p>\n\n\n\nRead<\/code> and ReadAsync<\/code> are automatically detected, with suggestions to replace them with the safer ReadExactly<\/code> API:<\/p>\n\n\n\nTuple Component Names<\/b><\/h2>\n\n\n\n
MyComponent<\/code>, rather than ItemN<\/code>. Our new IDE hint and corresponding quick-fix help you to get rid of generic names in favor of explicit names to make your code more readable:<\/p>\n\n\n\nReferencing Enum Member Names<\/b><\/h2>\n\n\n\n
nameof<\/code> operator was introduced in C# 6<\/a> \u2014 another case of \u201c10 years today\u201d! Since then, many have embraced it extensively to reference variable, type, and member names as string constants instead of using magic strings. ReSharper and Rider continue to spot situations [1<\/a>, 2<\/a>] in which you can make better use of them. Referencing an enum member through ToString<\/code> introduces unnecessary runtime overhead due to reflection and additional processing.<\/p>\n\n\n\nnameof<\/code> expression to reference enum member name<\/em> that targets such cases and provides a quick-fix to convert to nameof<\/code> as a compile-time language feature that is faster, safer, and clearer:<\/p>\n\n\n\nNameof with Unbound Generics<\/b><\/h2>\n\n\n\n
nameof<\/code> operator with unbound generics<\/a>. Previously, to get List<\/code> as a compile-time constant, you had to provide generic arguments \u2014 e.g., nameof(List<DontCare>)<\/code> \u2014 even though they are not included in the final name. This friction is now removed, and you can use the open generic as in nameof(List<>)<\/code>.<\/p>\n\n\n\nnameof<\/code> operators can be simplified and provide a quick-fix to remove redundancies:<\/p>\n\n\n\nFirst-Class Span Types<\/b><\/h2>\n\n\n\n
Span<T><\/code> and ReadOnlySpan<T><\/code> to provide more performant APIs. With C# 14, first-class support for span types is introduced through new implicit conversions<\/a> between ReadOnlySpan<T><\/code>, Span<T><\/code>, and T[]<\/code>, which are now applied in more scenarios. This makes working with spans more intuitive and seamless. ReSharper and Rider 2025.1 fully support these updated conversion rules:<\/p>\n\n\n\nSimple Lambda Parameters with Modifiers<\/b><\/h2>\n\n\n\n