26

I usually work with .NET using Git for versioning. In my team, we work in parallel and we often commit our code to integrate in the application. Everything is fine BUT the Visual Studio's solution and project files. We found two ways:

  1. Never commit those files, everyone has his own
  2. Include those file in the version system

Both ways have pros&cons, but basically we struggle every time we pull from central repo. Here some spare issues we found: (in parentesis, the reference to the above list)

  • We have to include other's files in the project (1) or include our newest (2)
  • If we work on different architectures (x86/x64) we have to manually change .csproj files (2)
  • Same issues replied for references and NuGet packages

and so on. Is there a proper workflow I can use?

Robert Harvey
  • 178,213
  • 47
  • 333
  • 501
balanza
  • 1,059
  • 1
  • 12
  • 34

3 Answers3

18

Committing .sln and .csproj files is usually the best practice (as in this answer), but merging requires some attention.
See "Why are my .csproj files getting messed up after a git rebase?".

*.csproj -text merge=union (see below)
*.sln -text merge=unionv

Or you can give up on .csproj and regenerate them locally as in this tweet.
Another reason to ignore those csproj files is if they are regenerated, as in this context

yellowblood warns (in the comments) about serious conflict issue with csproj file when used with the merge=union strategy.
That echoes the article "Merge conflicts in csproj files".
That is why there is a suggestion for VS IDE should support file patterns in project files (in order to not modify the .csproj file if one add a new .cs file that fits that pattern).

It's been suggested that if Visual Studio sorted its elements first, that would help mitigate the problem.
That helps reduce the incidental conflicts caused by Visual Studio's apparent non-deterministic sort of elements.
But it doesn't make the issue of merge conflicts go away.

ankostis
  • 8,579
  • 3
  • 47
  • 61
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 1
    I many VS projects \*.suo files get generated as well. Add `*.suo` to your .gitignore file. Plus you want to add the bin/* files for each project to your ignore file as well. They are all binary files. Also add the `TestResults` folder if you use MS Test or another unit testing framework. – Greg Burghardt Feb 02 '14 at 16:27
  • 1
    csproj should NOT have merge=union, it can cause really bad merges. – yellowblood Oct 13 '14 at 11:14
  • @yellowblood good point. I have edited the answer to make that risk very clear, and have added some links to support that recommendation (of *not* using `merge=union` for `.csproj` files). – VonC Oct 13 '14 at 11:23
  • 1
    File order is significant in .fsproj files, so sorting .csproj or supporting file patterns would just mask the issue. – brianary Sep 26 '17 at 00:32
6

In our project we check these into version control. We started with the .gitignore from github and a simple .gitattributes file:

# Auto detect text files and perform LF normalization
* text=auto

# Custom for Visual Studio
*.cs diff=csharp

This is because the union merge strategy can actually be dangerous for these files, see Merge conflicts in csproj files for details why this is not always safe and is probably not what you want.

You'll generally get merge conflicts every time but they're really easy to handle quickly in Visual Studio. An example case is adding a new empty project to a solution and committing it, then having multiple team members add different files to the project.

In theory you could have a custom merge driver defined that handles xml merges better, but I haven't seen that done by anyone else yet.

sme
  • 101
  • 1
  • 1
2

It's 2020-04-08 and my choice for this is mark csproj and sln files as binary, still trying to find a sturdy practice but it's still not existed.

Luke
  • 1,623
  • 3
  • 24
  • 32