Best practices for Subversion and Visual Studio projects

Question

I've recently started working on various C# projects in Visual Studio as part of a plan for a large scale system that will be used to replace our current system that's built from a cobbling-together of various programs and scripts written in C and Perl. The projects I'm now working on have reached critical mass for being committed to subversion. I was wondering what should and should not be committed to the repository for Visual Studio projects. I know that it's going to generate various files that are just build-artifacts and don't really need to be committed, and I was wondering if anybody had any advice for properly using SVN with Visual Studio. At the moment, I'm using an SVN 1.6 server with Visual Studio 2010 beta. Any advice, opinions are welcome.

Maishamaisie

This is VS2010 C#. There are some differences between this and VS2010 C++ for example. Give it the tag C#. – Metalanguage

Answer 1

According to MSDN:

You can add the following files to Visual Studio source control:

• Solution files (*.sln).
• Project files, for example, *.csproj, *.vbproj files.
• Application configuration files, based on XML, used to control run-time behavior of a Visual Studio project.

Files that you cannot add to source control include the following:

• Solution user option files (*.suo).
• Project user option files, for example, *.csproj.user, *.vbproj.user files.
• Web information files, for example, *.csproj.webinfo, *.vbproj.webinfo, that control the virtual root location of a Web project.
• Build output files, for example, *.dll and *.exe files.

Baneberry

That is a good list. Basically you want a minimal set of files needed to compile the projects. – Motive

There is a case to be made for committing the .user, at least in some cases. Those files one does not add should be added to svn:ignore. – Bamford

Those using Visual Studio 2015 will also want to exclude the .vs folder from source control. See https://mcmap.net/q/48381/-vs-folder-to-source-control-in-visual-studio-2015-duplicate/2615878. – Castalia

Answer 2

I would suggest using AnkhSVN - a Subversion source control plugin for Visual Studio 2008/2010.

You can use it to perform your initial add and commit of the solution, projects and sources to the repository and it won't add any of the build artefacts. It won't add anything that is generated by your build, only files that are referenced by your solution. If there are any other bits and pieces you need that aren't in your solution, you can add them afterwards.

Synonymy

I tried AnkhSVN, and found it tended to prematurely interpret actions within the IDE as actions on source control, and to encourage developers to make single-file commits. I am much happier with Tortoise. – Bamford

But it is useful that it knows what to ignore! – Bamford

Answer 3

Put the following files in version control:

• .dsw (VS6 workspace)
• .dsp (VS6 project)
• .sln (VS Solution)
• .*proj (VS Project files of various types)
• of course your source files and other artifacts you create

Do not put the following files into version control:

• .ncb (something to do with browsing or intellsense)
• .suo (user workspace settings like window placement, etc - I think)
• .user (user project settings like breakpoints, etc - I think)

Also, don't put in any object files, executables, auto-generated files (like headers that might be generated).

As for executables and other generated files - there might be an exception if you want to be able to archive releases. That might be a good idea, but you'll probably want to manage that a little differently and possibly in a different place than your source code. If you do this, also archive your .pdb files so you can debug the stuff later. you might want to use a Symbol Server to store you archived symbols (see Debugging Tools for Windows for the symbol server and its documentation).

Here's my list of VS-specific files that I exclude from SVN:

Ankh.Load
*.projdata
*.pdb
*.positions
*proj.user
*proj.*.user
*.ncb
*.suo
*.plg
*.opt
*.ilk
*.pch
*.idb
*.clw
*.aps

Mousy

Nit-picking: your say ‘don't put in ... executables’, but in the next paragraph you say one might! – Bamford

Answer 4

Solution level:

• add the .sln solution file
• ignore the .suo solution user options file

Project level:

• add the .csproj, .vbproj (and c++ proj?) files
• ignore the .csproj.user, .vbproj.user files
• ignore the bin directory
• ignore the obj directory
• ignore any files/directories that get generated during runtime (ie. logs)

If you use and VS addins, they may generate files that also need ignoring (ie. ReSharper generates .resharper and .resharper.user files).

The ignore items can either be ignored explicitly by filename (ie. MyProject.csproj), or by a wildcard pattern (ie. *.csproj.user).

---

Once you have your ignores set up, checking out a clean copy of your source then building should then show no modifications (ie. no new unversioned files).

Swedish

Answer 5

I would manually include all files that I think I shouldn't version control.

My global ignore pattern is:

.dll .pdb .exe .cache .webinfo .snk bin obj debug _Resharper .user resharper

Punctilio

Answer 6

In case you are using ignore list, SVN is case sensitive. So remember to ignore bin and Bin folders separately.

Also, I had a question.. why does it take lot of time some times to refresh the status icon? At times it gets very confusing.

Kuibyshev

Answer 7

See Mercurial .hgignore for Visual Studio 2008 projects for a Mercurial ignore list. I'm not familiar with the syntax of the SVN ignore list but this thread has a few good lists of what to ignore in Visual Studio.

Prentiss