Merging a common project with build variations in .NET MVC

Question

I have a .net mvc site that should be published to a lot of different customers, and thus vary slightly depending on the target.

Is there any way to set up the core project structure, e.g. (simplified):

• views
• models
• controllers
• assets
• bin

and make a merge at build time with whatever variations the current target might have. For example:

core project:

• views
  • view1.cshtml
  • view2.cshtml

(removed rest of the folders for brevity)

customer 1 target:

• views
  • view2.cshtml
  • view3.cshtml

desired merge result:

• views
  • view1.cshtml (from core project)
  • view2.cshtml (from customer 1 target)
  • view3.cshtml (from customer 1 target)

The same rule should apply to controllers, binaries etc.

Answer 1

I would either use multiple projects, nuget, or use source control. I will talk about these ideas below, but in no particular order. By the end I may include a preference towards one or the other.

First idea I'll talk about is to use multiple projects. Create your base project, let's call it WebBase. Create your core website that you have talked about. Next create Customer1 website, if you create Customer1 as an empty website you will need to recreate the folder structures in WebBase or you cane create it the same as you did with WebBase and remove all the files(do this from within Visual Studio); either way you end up with the folder structure with no files. I would recommend keeping web.config,packages.config, Properties folder with AssemblyInfo.cs. Then you will add the files from WebBase, but don't just add them normally. For illustration's purpose let's do the Home Index View: Expand the Views Folder in Customer1, Right click on home, choose add, choose Exising Item, browse out of Customer1 and then in to WebBase/Views/Home and single click index.cshtml, now notice the drop down on the button? click that and choose "Add as Link". Now do this for all the files in WebBase! It will seem cumbersome to choose "add as link" every time, but if you just click add, it will copy the file and updates won't propagate from WebBase to Customer1! Also, you will see things like remove from project vs delete (with prompt about permanent deletion).

Second thought would be to create a nuget package for WebBase and you can than install it as a package, the benefit of this approach would be versioning and it would not require you to update every project with each little change. It would keep each project completely isolated. Down side is you would need to update each project individually to propagate changes globally. You would need to learn about nuget's nuspec file and how to include files and such. It isn't that bad, it is just XML. But you can indicate which files to include when the package is installed/updated.

Third would be source control, I know with git you can use submodule to include a seperate project (even from external repository). Which might be an option, or you could just create a WebBase branch, setup WebBase and then branch it off into each Customer's website. So create a branch called Customer1, start adding the custom customer things. Switch back to WebBase, create a new branch called Customer2... you are off to the races. Switch back to WebBase, make a global change and then merge these changes into Customer1 and Customer2 branches.

Okay, I will admit it, I would probably go with the third option. It gives you lots of benefit with little downside. It even get gives you history! If you aren't currently using source control... you should! You can install git on your machine and have the ability to check code in locally and you don't have to worry about an external repository (although I would recommend you have one as it gives you DR).

Either way, there are options available. But nothing like a single project with configurable file includes.

Good luck!