Got to answer two question about multi-site configuration working with Sitecore:
1. Sitecore Multisite Best Practice for setting up Visual Studio Project (link to original question)
I'm seeking an advise on best practice that has worked for creating a asp.net MVC visual studio solution that supports multisite (multi tenant). One thing we would like to do is minimize the regression defects so that developer don't modify the wrong website code base etc.
That the solution needs to support more than 8 web sites.
2. Manage web.config in sitecore multisite solution (link to original question)
We have a multisite solution with individual visual studio solutions for each websites. Then we have master solution to build/deploy all websites.
Firstly, not sure whether it's a best practice to include web.config in Visual Studio solution. But I think all the nuget packages needs web.config to add their settings.
As a result, we have web.config for each solution. However when we deploy from master web.config gets overwritten by each sites. Could someone please suggest how this issue can be fixed?
Answers:
I have got one more alternative to address that. Currently working on
a huge project, with dozens of developers and quite bureaucratic
process of deployments, we have introduced the following approach:
- Project consists of multiple logical subparts, which in fact are individual websites.
- Each of those websites we set up as an MVC Area with own controllers, views etc
-
Most important - we set up MVC Areas as
individually pluggable DLLs. So each of that websites is a separate
project under solution, with its own resources and statics; on build
everything is copied under their required paths and DLL goes to the \bin
folder.
-
One more class library for shared (by all websites) resources, it is
being referenced only by those sites, that need that functionality
-
In Sitecore, we have the same strict principles - the content,
layouts, renderings are isolated as higher as possible, no individual
content may be re-used (unless from shared resources folder).
This approach serves us almost a year already and has proven for its agility, much easier deployment and fairly less code merge conflicts.
If you are working under just one site - you don't need to re-compile
and re-deploy everything - just replace one dll at bin folder.
Thus, combining that with your question, Approach 1 would be an answer.
References (more to read):
Regarding managing configuration, I would advise for each website (under its individual project) to create it's own App_Config/Include folder and create _project_name_.config within that folder in order to keep all site-specific settings there (for further merge into resulting config).
On build you set up (for each individual project) that file to be copied into main SITECORE_INSTANCE_WEB_ROOT\App_config\Include folder along with the rest of include patch config files.
Hope someone finds that helpful!
I want to share my experience of implementing MVC Areas as an individually pluggable (into the host website) DLL, that contains the code of specific area: controllers, models / view models, some area-specific DLL. The proof of concept was created by my great colleague Chandra Prakash, I decided to pick it after him and implemented in our product, so now it is 8 month as it works in production without any issues at all.
We are working in a big enterprise Sitecore-hosted project with more
than hundred of developers, so each deployment process may bring a pain.
Pluggable areas implementation has proven its concept and helped us to
keep updating only those parts of entire multisite Sitecore solution
that have been updated, without any risk of affecting the rest!
Features:
- no need to code anything in a host website, thus:
- no need to rebuild whole big outer solution - just rebuild (and replace) DLL
- no more need to struggle with complex dependencies
- simplified update: drop DLL into host website bin folder, and copy some static files referenced by this DLL - js, css, cshtml, img.
In day-to-day usage you will have the only one minor overhead of that implementation: 2 extra fields in controller rendering. In fact, instead of standard Controller Rendering we are using Area Controller Rendering that is derived from Controller Rendering just with addition of 2 extra fields required to resolve the area on a fly:
Sound attractive, isn't it? Then look how it is implemented - I address to the original article with more detailed explanations.
