Should I add the Visual Studio .suo and .user file

Question

Visual Studio solutions contain two types of hidden user files. One is the solution .suo file which is a binary file. The other is the project .user file which is a text file. Exactly what data do these files contain?

I've also been wondering whether I should add these files to source control (Subversion in my case). If I don't add these files and another developer checks out the solution, will Visual Studio automatically create new user files?

Answer 1

Others have explained why having the *.suo and *.user files under source control is not a good idea.

I'd like to suggest that you add these patterns to the svn:ignore property for 2 reasons:

1. So other developers won't wind up with one developer's settings.
2. So when you view status, or commit files, those files won't clutter the code base and obscure new files you need to add.

Answer 2

I wouldn't. Anything that could change per "user" is usually not good in source control. .suo, .user, obj/bin directories

Answer 3

You don't need to add these -- they contain per-user settings, and other developers won't want your copy.

Answer 4

No, you should not add them to source control since - as you said - they're user specific.

SUO (Solution User Options): Records all of the options that you might associate with your solution so that each time you open it, it includes customizations that you have made.

The .user file contains the user options for the project (while SUO is for the solution) and extends the project file name (e.g. anything.csproj.user contains user settings for the anything.csproj project).

Answer 5

They contain the specific settings about the project that are typically assigned to a single developer (like, for example, the starting project and starting page to start when you debug your application).

So it's better not adding them to version control, leaving VS recreate them so that each developer can have the specific settings they want.

Answer 6

Visual Studio will automatically create them. I don't recommend putting them in source control. There have been numerous times where a local developer's SOU file was causing VS to behave erratically on that developers box. Deleting the file and then letting VS recreate it always fixed the issues.