Best practices for storing an ASP.NET web site in Subversion?

Question

Hi there, I'm currently working on an ASP.NET project with multiple developers using Subversion for code distribution, but it's quite frankly totally messed up at the moment. The person who set up the Subversion repository have included config files specific to their computer, bin\* directories, and other such things.

I, being the guy who has to check out this repository and get it to run on my computer, am pretty frustrated by this since it's taken me a while to sort it all out to get it to compile at all. Now I'm thinking about writing a document for Subversion guidelines to send to the technical leader at my company so that we can get the process standardized and avoid these kinds of problems.

What I'm looking for is input on the guidelines. Here's the start for them, and hopefully we can make something good out of it:

The file structure should be set up to have third-party libraries checked in outside the build output directories (since they won't be included in the repository.) The name of this directory should be "Libraries".

No machine-specific files should be included in Subversion. Therefore, only a template of Web.config is checked in, which is customized by the developers to suit their machine. This behavior is included in Visual Studio 2010 by default and the individual configuration files (Web.Local.config) automatically have the template (Web.config) applied. The local configuration file still shouldn't be included in Subversion though, so long as it applies for a specific machine.

Solution and project files must not contain any absolute paths.

An ignore list should be set up. Start with:

'
*.user
obj
'

Example file structure for an ASP.NET 2.0 web site with a class library specific to the web site and a third-party library:

'
/trunk/
    Libraries/
        ThirdParty.dll
    MyClassLibrary/
        bin/  [Ignore]
        obj/  [Ignore]
        Properties/
            AssemblyInfo.cs
        SomeClass.cs
        MyClassLibrary.csproj
            - Holds references to third-party libraries. For example:
              ../Libraries/ThirdParty.dll
    MyWebApplication/
        bin/
            ThirdParty.dll  [Ignore; copied by build process]
            ThirdParty.dll.refresh
                - Contains "../Libraries/ThirdParty.dll"
        Default.aspx
        Default.aspx.cs
        Web.config  [Ignore]
        Web.config.template
    MySolution.sln
        - Holds list of projects.
        - Has reference information for projects.
'

An alternative to using Web.config.template would be to include a Local.config file from Web.config, but this might be less flexible.

When using a Web Application project rather than a Web Site project, the references will be stored in the project file instead of in .refresh files, so the bin/ folder will be ignored.

Can someone see errors in the above suggestions? Is something missing? Does anyone have suggestions for the ignore list? I just started with a couple of entries for now.

Answer 1

I think that you are a good step on the way. But why not put an ignore on the entire bin folder in /MyWebApplication, instead of the files? You wouldn't add your build output to subversion would you? I would definately consider that a bad practice.

Also, if possible, you could add the web.config file to subversion, but in the element reference a new file with appSettings: for example

<appSettings file="local.config">

Then have the local.config file be ignored by svn. That is how I always operate.

But of course that only works if every configurable parameter is in the appSettings (one of the reasons why I dislike the provider model, because all the providers need to get connection strings from a connectionString element, and you cannot reconfigure them to take a connection string from appSettings)

Edit: troethom enlightened me and pointed out, that you can also override the connectionString configuration settings in a separate file

<connectionStrings configSource="ConnectionStrings.config"/>.

So the thing that I would do is place the actual web.config file under subversion control, but let those other files that override the settings locally be ignored by svn.

Answer 2

You should add the .refresh files; not the real DLLs.

The Visual Studio project system sends a list of files that should be added to source control to SCC Providers. AnkhSVN is a Subversion SCC provider that uses this information to suggest adding these files (and not the other files).

VisualSVN and other Subversion clients that only look at file extensions don't get this information from ASP.Net.

(Note: if you remove the .refresh file, Visual Studio will add the DLL to the list of files that should be committed)