We have developed a system that uses a single code base, consisting of four Visual Studio projects with an admin website, and customer facing website (each system has its own MS
I ran into this exact problem a few months ago when we started a significant rewrite of our web app. We had two separate versions of nearly identical sites. The back-end code was 99% identical, while the JavaScript, CSS, and other front-end stuff was very different. We had these two sites in separate trunks in the same SVN repository, and it soon became a nightmare of copying & pasting common code between them. Patching and merging was too painful to be useful, due to slight variations in the files.
Our solution was neither SVN-related nor builing of a common library. Instead, the concept of a separate site is defined in a single codebase via multiple config files and a heirarchy of CSS, image, and language resource files. Site-specific features are enabled by config values.
Each site gets a unique name (say, "foo" and "bar"), which is retrieved from the Web.config file at run-time. The name is used to determine which config file is loaded and which client-side files to use. The setting is blank in SVN. It is set by our deployment scripts when copied to the web servers. On our local development machines, an environment variable defines the site we want to work with.
The file structure of the site-specific files would look like this:
|- Config
| |- AppSettings.foo.config <- overrides Web.config AppSettings for "foo" site
| |- AppSettings.bar.config <- overrides Web.config AppSettings for "bar" site
|- Content
| |- CSS
| |- main.css <- default CSS file for all sites
| |- main.foo.css <- CSS overrides for "foo" site
| |- Images
| |- logo.jpg <- default logo
| |- logo.foo.jpg <- logo used if site name is "foo"
| |- logo.bar.jpg <- logo used if site name is "bar"
This has worked great for us, so far. Adding a new feature to a specific site is as easy as adding the feature to our code-base, and only enabling it for that site.