Conflicted suo files are the bane of every developer’s existence. I have been using SVN as my code repository for years now. I must admit that I probably don’t know it as well as I should. Unfortunately I know it as well as I need to, which is a totally different thing. You see, developers are generally lazy. Why re-do work if you can do it once and re-use.
The same can be said of what we know about the tools we use. Once we are comfortable with what we know and can work with, we somehow fail to learn more. Call it knowing just enough to be functional, call it lazy, call it what you want. Somehow, I feel that we should learn more.
I can actually see this tendency in the occurrence of conflicted .suo files in Visual Studio projects checked out of the SVN repository. We all know that we should ignore the bin and obj folders, but why is it that so many developers check in the .suo file as well?
Conflicted suo file
As soon as we start working in teams, the .suo file will tend to move into a conflicted state with everybody checking in their .suo files. You see, the .suo file is actually just the file that contains user-specific Visual Studio settings. These settings are the locations of all your breakponts for example. Other settings also include your Visual Studio window layout (do you have Server Explorer window open. If so where is it located in your IDE). It should come as no surprise then that the .suo extension stands for ‘Soluton User Options’. According to MSDN, the .suo file is defined as follows:
“The solution user options (.suo) file is a structured storage, or compound, file stored in a binary format. You save user information into streams with the name of the stream being the key that will be used to identify the information in the .suo file. The solution user options file is used to store user preference settings, and is created automatically when Visual Studio saves a solution.”
Fixing the Conflicted suo file
Fixing your conflicted .suo file is actually really easy. You can just simply delete the conflicted suo file from Subversion. It does not need to be in the code repository. If however you feel that fixing the conflict is better, you can do it whichever way you like (‘Resolve using theirs’ or ‘Resolve using mine’). Obviously your personal settings in Visual Studio don’t make any difference to the actual code of your solution. It is for this reason that the .suo file should not be stored in source control. It will only cause endless conflicts because no two users in a development team would have the same settings. It is also for this reason that you can resolve the conflict (if you want to) any way you see fit. My recommendation would however be to just remove it from your source control to begin with.
If any of you have any tips & tricks to share, please do so in the comments below.
Reference: Bite The Wax Tadpole