Mass refactorings in .NET: a brainstorming session

There are certain scenarios where adapting the code of many microservices becomes necessary. One common case is supporting a new feature. In other instances, a refactoring might be required due to a URL change affecting multiple services. Additionally, migrations such as upgrading the .NET version or switching to another log storage can demand widespread modifications. When making such changes across multiple repositories, several challenges become apparent. The work is sometimes tedious. In the best-case scenario, there is a well-defined instruction set to follow. But even then, human errors are inevitable. You may forget to adapt the configuration, overlook dependencies or misapply changes, leading to debugging sessions. Reviewing such changes may be exhausting, which could result in unnoticed mistakes being deployed. The overall effort is substantial, often causing teams to postpone these refactorings despite their necessity. To mitigate the risks and ease the developer experience, automation or at least partial automation becomes essential. Teams can streamline repetitive tasks by leveraging scripting and refactoring tools to apply changes across multiple repositories. Therefore, I want to use this blog entry to gather some ideas and questions about how such a system may look like for the .NET environment (as I'm a .NET developer myself). Existing tools Here are two already existing tools for use: multi-gitter multi-gitter is a tool developed by lindell allowing developers to apply scripts and create merge/pull requests across many repositories. I already used it and was impressed by how much time I saved when having to tweak small things (adding a new file, config change, ...) across multiple repos. OpenRewrite by Moderne Openrewrite describes itself as a refactoring ecosystem. It allows developers to run recipes (your code changes) across multiple repositories. By utilizing a Lossless Semantic Tree and Java-based code, it is possible to refactor the code of your applications. One can run these recipes via theconsole. Moderne (the company behind OpenRewrite) also offers a cloud platform with a frontend to run the recipes Questions for .NET mass refactorings Several key questions arise when considering automation for mass refactorings in .NET: Can the Roslyn API be utilized for automated refactorings? Roslyn provides capabilities for analyzing and modifying C# code. Would it be possible to use it to apply C# code changes efficiently? How do we handle refactorings beyond C# code? While we may use Roslyn for C# code, adaptations will be necessary for configuration files (.yaml, .csproj, .json, ...). How would a support for changes to these files look like? How could we combine refactorings for both c# and other files? What does an ideal developer experience look like? Should such a tool be designed as a GUI-based application, a CLI tool or be connected to an IDE (looking at developing roslyn scripts)? What would be the most efficient solution? What is the best way to structure refactorings for easy sharing across multiple teams? A very central question as it massively impacts developer experience. Related questions to the architectural design of the tool are: In what form should refactoring code exist? Should it be packaged as a NuGet library? Should it be stored in a repository that developers need to clone? I'm looking forward to exploring this topic in the following weeks.

Apr 26, 2025 - 16:23

Mass refactorings in .NET: a brainstorming session

There are certain scenarios where adapting the code of many microservices becomes necessary. One common case is supporting a new feature. In other instances, a refactoring might be required due to a URL change affecting multiple services. Additionally, migrations such as upgrading the .NET version or switching to another log storage can demand widespread modifications.

When making such changes across multiple repositories, several challenges become apparent. The work is sometimes tedious. In the best-case scenario, there is a well-defined instruction set to follow. But even then, human errors are inevitable. You may forget to adapt the configuration, overlook dependencies or misapply changes, leading to debugging sessions. Reviewing such changes may be exhausting, which could result in unnoticed mistakes being deployed. The overall effort is substantial, often causing teams to postpone these refactorings despite their necessity.

To mitigate the risks and ease the developer experience, automation or at least partial automation becomes essential. Teams can streamline repetitive tasks by leveraging scripting and refactoring tools to apply changes across multiple repositories. Therefore, I want to use this blog entry to gather some ideas and questions about how such a system may look like for the .NET environment (as I'm a .NET developer myself).

Existing tools

Here are two already existing tools for use:

multi-gitter

multi-gitter is a tool developed by lindell allowing developers to apply scripts and create merge/pull requests across many repositories. I already used it and was impressed by how much time I saved when having to tweak small things (adding a new file, config change, ...) across multiple repos.

OpenRewrite by Moderne

Openrewrite describes itself as a refactoring ecosystem. It allows developers to run recipes (your code changes) across multiple repositories. By utilizing a Lossless Semantic Tree and Java-based code, it is possible to refactor the code of your applications. One can run these recipes via theconsole. Moderne (the company behind OpenRewrite) also offers a cloud platform with a frontend to run the recipes

Questions for .NET mass refactorings

Several key questions arise when considering automation for mass refactorings in .NET:

Can the Roslyn API be utilized for automated refactorings?

Roslyn provides capabilities for analyzing and modifying C# code. Would it be possible to use it to apply C# code changes efficiently?

How do we handle refactorings beyond C# code?

While we may use Roslyn for C# code, adaptations will be necessary for configuration files (.yaml, .csproj, .json, ...). How would a support for changes to these files look like? How could we combine refactorings for both c# and other files?

What does an ideal developer experience look like?

Should such a tool be designed as a GUI-based application, a CLI tool or be connected to an IDE (looking at developing roslyn scripts)? What would be the most efficient solution?

What is the best way to structure refactorings for easy sharing across multiple teams?

A very central question as it massively impacts developer experience. Related questions to the architectural design of the tool are: In what form should refactoring code exist? Should it be packaged as a NuGet library? Should it be stored in a repository that developers need to clone?

I'm looking forward to exploring this topic in the following weeks.