visual-studio delete - Should I add the Visual Studio.suo and.user files to source control?
where located (15)
We don't commit the binary file (*.suo), but we commit the .user file. The .user file contains for example the start options for debugging the project. You can find the start options in the properties of the project in the tab "Debug". We used NUnit in some projects and configured the nunit-gui.exe as the start option for the project. Without the .user file, each team member would have to configure it separately.
Hope this helps.
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?
By default Microsoft's Visual SourceSafe does not include these files in the source control because they are user-specific settings files. I would follow that model if you're using SVN as source control.
I wouldn't. Anything that could change per "user" is usually not good in source control. .suo, .user, obj/bin directories
These files are user-specific options, which should be independent of the solution itself. Visual Studio will create new ones as necessary, so they do not need to be checked in to source control. Indeed, it would probably be better not to as this allows individual developers to customize their environment as they see fit.
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).
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.
Since I found this question/answer through Google in 2011, I thought I'd take a second and add the link for the *.SDF files created by Visual Studio 2010 to the list of files that probably should not be added to version control (the IDE will re-create them). Since I wasn't sure that a *.sdf file may have a legitimate use elsewhere, I only ignored the specific [projectname].sdf file from SVN.
Why does the Visual Studio conversion wizard 2010 create a massive SDF database file?
If you set your executable dir dependencies in ProjectProperties>Debugging>Environment, the paths are stored in '.user' files.
Suppose I set this string in above-mentioned field: "PATH=C:\xyz\bin" This is how it will get stored in '.user' file:
This helped us a lot while working in OpenCV. We could use different versions of OpenCV for different projects. Another advantage is, it was very easy to set up our projects on a new machine. We just had to copy corresponding dependency dirs. So for some projects, I prefer to add the '.user' to source control.
Even though, it is entirely dependent on projects. You can take a call based on your needs.
Using Rational ClearCase the answer is no. Only the .sln & .*proj should be registered in source code control.
I can't answer for other vendors. If I recall correctly, these files are "user" specific options, your environment.
This appears to be Microsoft's opinion on the matter:
I don't know why your project stores the DebuggingWorkingDirectory in the suo file. If that is a user specific setting you should consider storing that in the *.proj.user filename. If that setting is shareable between all users working on the project you should consider storing it in the project file itself.
Don't even think of adding the suo file to source control! The SUO (soluton user options) file is meant to contain user-specific settings, and should not be shared amongst users working on the same solution. If you'd be adding the suo file in the scc database I don't know what other things in the IDE you'd break, but from source control point of view you will break web projects scc integration, the Lan vs Internet plugin used by different users for VSS access, and you could even cause the scc to break completely (VSS database path stored in suo file that may be valid for you may not be valid for another user).
Alin Constantin (MSFT)
You don't need to add these -- they contain per-user settings, and other developers won't want your copy.
These files contain user preference configurations that are in general specific to your machine, so it's better not to put it in SCM. Also, VS will change it almost every time you execute it, so it will always be marked by the SCM as 'changed'. I don't include either, I'm in a project using VS for 2 years and had no problems doing that. The only minor annoyance is that the debug parameters (execution path, deployment target, etc.) are stored in one of those files (don't know which), so if you have a standard for them you won't be able to 'publish' it via SCM for other developers to have the entire development environment 'ready to use'.
On the MSDN website, it clearly states that
The solution user options (.suo) file contains per-user solution options. This file should not be checked in to source code control.
So I'd say it is pretty safe to ignore these files while checking in stuff to your source control.
.user is the user settings, and I think .suo is the solution user options. You don't want these files under source control; they will be re-created for each user.
Here is what I use in my .NET Projects for my
[Oo]bj/ [Bb]in/ *.suo *.user /TestResults *.vspscc *.vssscc
This is pretty much an all MS approach, that uses the built in Visual Studio tester, and a project that may have some TFS bindings in there too.