Deploy project with same code base but different content to multiple sites

Question

I have an ASP.NET MVC project that is deployed via Visual Studio's Web Deployment - all works fine so far.

I now need to deploy another version of the same project (e.g. for a different customer) - with the same code base/functionality, but with a different layout, i.e. other CSS and images (maybe even with different views/Razor code). Ideally, the content from the other configuration would not be published at all.

I know I can use different connection strings for the persistence layer - but is there a way to configure also configure other content elements?

I'd like to avoid having two versions (or later even more) that required branching/merging - but rather like to simply deploy the latest version with the different "themes"...

Answer 1

I have a MVC project with 4 class libraries. And i deployed it into 3 other domains.

I copied only MVC project without controllers or code classes for each client, and added them into my solution. I use them only for visual changes or themes. Not for server side functionality. So the copied projects' assemblies shouldn't be deployed. Only the UI files should be deployed. Assemblies are deployed from the original MVC project's output folder.

I build solution and publish dll's into 3 domain, and publish only each client's UI files into it's server.

This enables me to develop server-side functionality in only one MVC project. Separate UI files from server side functionality.

Hope this helps.

Answer 2

are you using MVC then?

What you can do is to override the default razor engine and create your own. What the razor engine does is mainly to map your requests to views in particular folders, you can tell the razor engine when to map those requests to views in one folder or another.

MVC4 Razor Custom View Locator

A full fledged explaination is here :

http://nickberardi.com/creating-your-first-mvc-viewengine/

That is for views, if you just want the CSS or JS to be different, you just have to map your requests to a razor bundle and then vary what the content of the bundle is depending on a variable, or the pressence of a configuration file, or by filling a variable with a value from the database. As you can see here bundling is very easy :

http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification

Say your html points to : /assets/mycssbundle.css , but what that file would actually contain can be altered by where you tell to the bundling function that the files are located.

Answer 3

This seems like a design question. If you foresee possible changes like this in the future, and you already swap content via DB, then you should consider loading css file from database. There're of course many other ways to do this but simple and efficient is preferable.

This would mean structuring your html properly to ensure all layout is properly handled via CSS and can be achieved via ViewData or ViewBag. See case example.

Edit: Not css data but the relevant css file.

Answer 4

You have two options:

A) Develop a custom view engine that switches between different page sets depending on the configuration. This will allow you to switch between the page sets just by changing the web.config settings, which fits well with the visual studio's built in deployment model (different web.config transformations kick-in for different deployment environments). One implementation that comes to mind - switch between view engines for different deployment environments (in different web.config transformations).

Unlike the other suggestion to load pages from the DB, I would recommend loading them from folder or physical location (e.g. different view engines targeting different sub-folders of the project). DB approach is not developer friendly when it comes to developing and fixing pages and their markups that are in the DB.

B) Develop all page sets (all variations) under the same project and then write custom deployment scripts which deploy particular page sets depending on the deployment environment. Drawback of this approach is that it's hard to notice issues like page sets intersecting or links crossing the page set boundaries.

While plan B sounds a little bit simpler development-wise, it can become a nightmare maintenance- and deployment-wise.

So, I recommend plan A.