Which c# project files should I version control?

Question

I have a project I'm looking to manually manage via perforce version control as I only have the Express edition. What I'm looking for is which files should be excluded in the version control as locking many of the files can result in a problem for visual studio compiling and debugging.

What I have, so far, included.
.cs files (except properties folder)
.resx files
.csproj files

Excluded
bin folder
obj folder
Properties folder
.user file

Let me know if there is something more that should be included that I have excluded or if there is a better way to do this.

Answer 1

You should include the Properties folder; it contains AssemblyInfo.cs (with all of the assembly attributes) and the project's default Resources and Settings files, if any.

You should also include the .sln file, if any.

Answer 2

Also exclude:

.suo
app.config (you should commit something like app-dev.config instead)

Re: app.config:

app.config usually contains machine specific info (like database connection strings, default settings, or paths to resources) and you don't want this clobbered everytime you check out from source control. These files should be created/copied with deploy scripts.

When there are multiple developers on a project each with their own database server, this is especially annoying. The reverse can be even more dangerous - if you deploy code to production by checking out from revision control, you may inadvertently set production to use a development database, which could be disastrous.

Answer 3

Don't forget to add any images, icons etc. you might be using in your application. It's easy to forget these.

Also if you have any documentation associated with the project - specifications, designs, help files etc. Put these into separate folders under the project and then include them too.

Answer 4

If I am using third party DLLs I version control them with the project, and use side-by-side deployment such that the DLL is copied to the bin folder during compilation(as opposed to just registering the DLL in the GAC). The effect of this is another developer can pull the project down from source control and have the dependencies they need to successfully compile and run the project. There is no wasteful downloading and installing of third party components, and you are sure everyone is developing/testing against the same version of the third party dll.