Dealing with merge conflicts in the solution (.sln) file is a pain, and it seems I am not the only one annoyed by the cryptic format:
Sadly Microsoft hasn’t done anything to improve the situation (yet), but people in the .NET community has played around with creating a new format for the solution file: JeffCyr/MSBuild.SolutionSdk .
While such an approach is very interesting and could be the future of .NET solutions, I wanted something a bit less drastic. At least for now
Approach
I decided to approach it somewhat differently. Instead of replacing the sln file all together, I decided to solve it with an object-oriented approach; by putting a layer of abstraction in front of the sln file
I like the yaml format for its readability, and decided to use this format for the abstracted solution file. The idea being to use a yaml specification of the solution to generate a “clean” solution file. The yaml specification, being much simpler to read and reason about, should be much easier to resolve merge conflicts in
I have published this tool as a .NET tool on NuGet: dotnet-simple-sln
You can install it globally with:
dotnet tool install -g dotnet-simple-sln
Usage
Usage is pretty simple:
To start using it with an existing solution, use the derive
command:
simple-sln derive -i MySolution.sln
which will derive a yaml specification from the solution named MySolution.sln.yaml
.
After checking this file into git, you can keep it up-to-date by also adding a git pre-commit hook:
#!/bin/sh
SLN_FILE="SimpleSolution.sln"
simple-sln cleanup -i ${SLN_FILE} -s
git add "${SLN_FILE}" "${SLN_FILE}.yaml"
which runs the cleanup
command on the solution file, and optionally adds the updated sln and yaml files to the commit.
You can omit or comment out the git add ..
line if you don’t want to automatically include the updated .sln
file in your commit.
You can also just omit -s
from the command and "${SLN_FILE}.yaml"
from the git add
line if you don’t want to automatically include the updated .sln.yaml
file in your commit
After setting this up, the sln file should be aligned no matter which IDEs and IDE versions (looking at you VS) that your team members are using.
That alone should reduce the number of merge conflicts. And checking in the solution specification file should make reviewing changes to the solution structure much simpler, especially if your team is using virtual folders in the solution