Should I add the Visual Studio .suo and .user files to source control?

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?

Descent

.suo files are recreated automatically. A great way to 'refresh' you settings to default if things break. – Punjabi

Best practices for Subversion and Visual Studio projects is a more generic question about this exact topic. Also the accepted answer of it contains a link to official MSDN documentation, which describes in detail which files / directories of VS solutions / projects should be added to source control systems, and which parts should be ignored. – Shephard

for *.suo, please see here: msdn.microsoft.com/en-us/library/bb165909.aspx – Saul

Which Visual C++ file types should be committed to version control? – Eggert

There is a very easy way to determine if you should include a particular file in version control. Delete the file. Does your app still build and execute as expected? If so, the file should not be included. – Lymphocyte

Answer 1

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'.

Lucky

Be careful, suo file stores information whether project is loaded/unloaded within solution. – Shiekh

I believe it stores the debug info in the .user file (at least for SQL Server Data Tools). Also, when you change the settings in the Debug tab, it's not always persisted to .user straight away (closing the solution seems to work, bit annoying... or changing another setting stored in the .sqlproj file). – Slaveholder

You can open both the .user and the .csproj files in any text editor. I just tested copy-pasting the relevant debug settings from the .user into the .csproj, then deleting the .user file. Debugging continued to work, happily reading the correct settings from their new location in the .csproj file. This should provide a way to commit debug settings without committing the .user file. Be sure you put them in the right configuration (debug, release, etc). Works on my machine! =) – Trypanosome

@ChrisNielsen do the manually-inserted properties appear in the GUI in Visual Studio? I seem to have debugging working, but it looks mysterious as the field values aren't showing up in Visual Studio – Stator

Answer 2

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

Innocuous

If you're working by yourself on several different machines would it be worth it to add them? – Citole

I wouldn't, because it may be fragile to unexpected system differences; for instance, if you work on x64 at work and x86 at home, then it might choke over "c:\program files (x86)" and "c:\program files". I don't know, but I wouldn't risk it. – Innocuous

Though they contain user specific information , but the information of files that are newly added via (include in project) option is also in .csproj file i think , which requires the other users to manually add all the newly added project resources. If anybody knows a workaround, please mention here. – Fluvial

Answer 3

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.

Hoitytoity

Where and how is the svn:ignore property set? – Aborn

@PeterMortensen, see this question: #86549 – Hoitytoity

But there is a case (see this answer) for adding the .user, so then one may choose not ignore only .suo – or one could ignore .user, so that it takes a conscious decision to add them? Don’t think so, the point of svn:ignore is marking things where no conscious decision is needed. – Invalidity

Answer 4

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.

Arrear

I'm also starting to think this should be the case - commit the user file so developers in a team use same debug settings. If they change it on their own machine, still fine, as long as the standard way is the version in source control. – Slaveholder

Others have suggested against doing this, but I'm not sure what the dangers might be. Maybe because the repo file with less precise settings would blow away the user's (better) local copy? (Our team is using Mercurial, BTW.) – Cotten

Microsoft advises against adding the .user file to source control. – Carlile

You can move the debug settings to the .csproj, see this comment – Variety

you could just add a differently named copy of the standard user settings. – Quarterly

The danger of adding the user file to source control is that if one developer changes their local debug settings and then accidently checks in their updated user file with another commit (an easy thing to do) then the debug settings are changed for everybody in the team when they get the updated user file. Better in my opinion to exclude it and configure the debug settings for each developer manually (referring to a readme or project website for example). – Podvin

Answer 5

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?

Daedal

SDF file is probably a SQL Server Compact Edition database. – Firepower

Answer 6

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).

Kitchenware

Answer 7

This appears to be Microsoft's opinion on the matter:

Adding (and editing) .suo files to source control

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)

Plutocrat

Also, from MSDN: Solution User Options (.Suo) File. The first sentence makes Microsoft's intent quite clear: "The solution user options (.suo) file contains per-user solution options. This file should not be checked in to source code control." – Carlile

Answer 8

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.

Seasonseasonable

Answer 9

No.

I just wanted a real short answer, and there wasn't any.

Grassofparnassus

Answer 10

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.

Formication

I had the .sou file left over and it was giving problem reloading the packages. Deleting the .sou file fixed the issue. Thank you. – Scibert

Answer 11

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.

Fisherman

Answer 12

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

Pachalic

Answer 13

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.

Winfrid

Answer 14

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.

Nunnally

Answer 15

You cannot source-control the .user files, because that's user specific. It contains the name of remote machine and other user-dependent things. It's a vcproj related file.

The .suo file is a sln related file and it contains the "solution user options" (startup project(s), windows position (what's docked and where, what's floating), etc.)

It's a binary file, and I don't know if it contains something "user related".

In our company we do not take those files under source control.

Irby

Answer 16

.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.

Romanticism

Answer 17

Others have explained that no, you don't want this in version control. You should configure your version control system to ignore the file (e.g. via a .gitignore file).

To really understand why, it helps to see what's actually in this file. I wrote a command line tool that lets you see the .suo file's contents.

Install it on your machine via:

dotnet tool install -g suo

It has two sub-commands, keys and view.

suo keys <path-to-suo-file>

This will dump out the key for each value in the file. For example (abridged):

nuget
ProjInfoEx
BookmarkState
DebuggerWatches
HiddenSlnFolders
ObjMgrContentsV8
UnloadedProjects
ClassViewContents
OutliningStateDir
ProjExplorerState
TaskListShortcuts
XmlPackageOptions
BackgroundLoadData
DebuggerExceptions
DebuggerFindSource
DebuggerFindSymbol
ILSpy-234190A6EE66
MRU Solution Files
UnloadedProjectsEx
ApplicationInsights
DebuggerBreakpoints
OutliningStateV1674
...

As you can see, lots of IDE features use this file to store their state.

Use the view command to see a given key's value. For example:

$ suo view nuget --format=utf8 .suo
nuget

?{"WindowSettings":{"project:MyProject":{"SourceRepository":"nuget.org","ShowPreviewWindow":false,"ShowDeprecatedFrameworkWindow":true,"RemoveDependencies":false,"ForceRemove":false,"IncludePrerelease":false,"SelectedFilter":"UpdatesAvailable","DependencyBehavior":"Lowest","FileConflictAction":"PromptUser","OptionsExpanded":false,"SortPropertyName":"ProjectName","SortDirection":"Ascending"}}}

More information on the tool here: https://github.com/drewnoakes/suo

Deon

Answer 18

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.

Coaming

only the .sln & .*proj should be registered - didn't you forget a lot of files here? – Drin

@Drin besides the obvious – Sileas

Answer 19

Don't add any of those files into version control. These files are auto generated with work station specific information, if checked-in to version control that will cause trouble in other work stations.

Phrase

Answer 20

No, they shouldn't be committed to source control as they are developer/machine-specific local settings.

GitHub maintain a list of suggested file types for Visual Studio users to ignore at https://github.com/github/gitignore/blob/master/VisualStudio.gitignore

For svn, I have the following global-ignore property set:

*.DotSettings.User
*.onetoc2
*.suo
.vs
PrecompiledWeb
thumbs.db
obj
bin
debug
*.user
*.vshost.*
*.tss
*.dbml.layout

Adrianaadriane

Answer 21

As explained in other answers, both .suo and .user shouldn't be added to source control, since they are user/machine-specific (BTW .suo for newest versions of VS was moved into dedicated temporary directory .vs, which should be kept out of source control completely).

However if your application requires some setup of environment for debugging in VS (such settings are usually kept in .user file), it may be handy to prepare a sample file (naming it like .user.SAMPLE) and add it to source control for references.

Instead of hard-coded absolute path in such file, it makes sense to use relative ones or rely on environment variables, so the sample may be generic enough to be easily re-usable by others.

Bascio

Answer 22

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:

<LocalDebuggerEnvironment>PATH=C:\xyz\bin$(LocalDebuggerEnvironment)</LocalDebuggerEnvironment>

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.

Underneath

Symbolic links also work very well for this purpose. – Setter

Instead of hard-coding absolute paths, it makes sense to rely on environment variables (like PATH=$(PGSQL_ROOT)\bin - a sample from a real project working with PostgreSQL). – Bascio