The .csproj file should definitly be there imho. For the .sln file there are different practises, I personal add it to make it as easy as possible for new developers to get the project up and running (they should just be able to download, build and go). For the web.config file I have a resources folder with the different web.config files placed in it (for local development, test server, staging, production etc). For the app settings I've started creating an appsettings.config file which I link to in my web.config file (which is under source control). I also have a library and reference folder for external projects and 3rd party dlls.

Hope this helps.

Frederik 

.sln and .csproj files should defenitely be checked in. What we do in our project (several developers working on the same files), is that we have a web.config.local, log4net.config.local, etc and we use BeyondCompare to find changes in these files when there are changes in the config files. 

 You should not add config files or compiled dlls to subversion. And having a separate reference folder with external references etc is also good practice.

 That's my point of view :) 

As a true believer of the benefits from having all developers work the same way I would recommend also sticking the .config files in the svn repo. if you are many devs working on the same project from time to time this would be especially important.

 

Cheers 

No, do NOT put the .config files in svn repository. You need to be able to have independent changes to the config files that you should not commit.  That's why I suggested the solution with .local or .build ending to the .config files.

The problem with this is that you would need some automatic merging of these files into one "master" .config when you check them in. People tend to forget to merge changes that might affect the other developers local environment. Lets say developer A commits some code that has a dependency on som appSettings from the web.config… Developer B updates his code and then his environment is broken… The most common reason developers have different config files is that have their own preferences for where to locate the VPP folders amongst other things. It might be possible to split such configurations into separate config files using the configSource attribute (like you would do with the connectionsstrings element). However if you have a company standard on the locations of the VPP’s, log directories etc. this might be a simpler solution. 

I agree with Lars Flågan. Commit your config files and strive to keep them developer independent. I rather force developers to check out to the same drive and location (to keep directory structures the same on all machines).

If you have to change web.config for a period of time, and don't want to commit it by accident, put it into the "ignore-on-commit" changelist in TortoiseSVN which will make it unchecked by default in the list of changed files during commits. 

I agree on smaller simple projectes. But, if you are working on larger projects where you have different service enviroments to work against, different handlers people are working on, and other independent differences, I think it is totally wrong to commit the config files. I'm working on a project where we have been 5-8 developers working on the project. It would be a nightmare if all of us were to commit all config file changes. 

Lars, I have seen the technique you describe fail in big projects with many developers. Committing config files is not just for small and simple projects. I agree that committing config files fits best in smaller projects though.

The most important thing is to find something that works (and I believe committing config files does work) and then adjust as the needs dictate.

One technique I have been thinking about (if web.config is not committed) is to have an xsd file for important settings (those that needs to be defined and have no sensible default values). If developer A adds a setting that all developers should have in their config files, it is added to the xsd file and committed. When developer B updates and builds, a pre-build event is run that sees the missing setting in web.config. The build is then broken until the setting is added.

The same xsd file can be used on test and production servers to verify that the web.config files have the neccessary settings defined.

When working in lager teams project setups become more important, hence you would want to stick everything into the version control system. Off course this requires more "planning" when it comes to how you set up your projects, solutions and source code repositories. But it would be well worth the effort if you can minimize repetitive and error prone tasks such as manually copying changes from a local config into a "global" config.

When considering which files to check in to the repository you need to think about why you are using a versioning system... Most commonly you use it because you want to be able to roll back to a previous version of a file because something is wrong with the current version. My opinion is that this also applies to config files