Hi! The problem I'm facing is that it seems that some of the files generated by Visual Studio are not necessary for commits.
Aside from the obvious things not to commit, what other files should I not commit? Do I need to commit .manifest files, etc.?
A different way of saying it: what files are needed to recreate the project I'm working on, and what files can be auto-generated?
Thanks!
The files I usually don't commit are: *.suo and *.user. I commit most other files.
Binary files can be committed or not depending on your company policy. In theory you should be able to recreate them again from the source code, but in practice it is a good idea to have an exact copy of anything you have sent out to a customer. So at least for releases the binaries should be committed.
In general, its a bit difficult to specifically list the files as it depends a lot on what kind of project you have and tools if any you use for autogeneration of code.
In general, the .suo file is something that is user specific and shouldnt be checked in.
However, the easiest way that i can suggest to you is to
If it builds, great. If not, you then add files till it does.
It is a bit trial and error, but most likely its going to be only a one time thing.
Other option is to actually find out for each type of unknown file exactly what it does and then decide whether it is needed or not and accordingly exclude / include. For this, if you post the extensions of the files you arent sure of, either google / SO can help!!
Personally, i dont believe in commiting binaries at all, even for releases. Seems unnecessary to me as in our case, every release has a label associated with it. So getting the exact code that was released is just a question of getting the code associated with the label and building it. Also, since deployment is usually via setup files, as long as you have the setup msi / exe (and as long as you are keeping backups of those for your releases) having all the binaries checked in into source control seems a bit of overkill