There are three aspects in choosing a DI approach with Sitecore 8.2:
The decision of which dependency injection container to use.
The way you integrate the container with Sitecore and ASP.NET MVC.
The pattern in which service dependencies and implementations are registered.
Picking a DI container
Sitecore 8.2 uses IServiceProvider / IServiceCollection as ...
Habitat is intended to inspire your solutions; you should never start with the Habitat solution and add to it when creating a new site. Habitat is not an accelerator, it is an example of the Helix principles outlined here: helix.sitecore.net.
When you create a new solution, you may want to refer to the Habitat solution for things like:
Solution structure (...
A Resounding No
Think of Sitecore Habitat as the result of an assess and plan project phase where requirements and business objectives were already described for a ficticous client and developed.
While thats great for a demo site, as it goes, most requirements differ wildly per client. Using this as a starter kit, places unfounded requirements that maybe ...
You might want to consider psake. It is a task based build system written in Powershell.
A good starting point would be this piece of code:
# Let's define layers here
$layers = @( "Foundation", "Feature", "Project" )
# These folders we want to copy to our target
$foldersToCopy = @( "Views", "bin", "App_Config" )
# This is the default task which will run ...
From a architectural point of view there is no reason not to have everything in a single project. This will certainly make load and build times quicker - if that is the aim.
The reason for splitting up modules into projects is to clearly define boundaries for modules so that dependencies are as visible as possible, which increases productivity, reduces cost ...
I'm not entirely sure there is a "recommended" approach - it mostly boils down to the container you'd like to use and the features you'd like to leverage from that container.
For instance, if you like non-conforming containers like Simple Injector and want to use the Verify() method on the container, then an approach like Rich's, in your third link, is a ...
You would need to use an XmlTransform to do this. If you look at the Habitat demo site you can see examples of how to do this.
Creating the transform file
You would add your connection string to a ConnectionStrings.config.transform file - this can live in your project in the App_Config folder.
The file is a standard config transform file. Example:
Every single answer you will receive will be a no, Habitat is not mean to be used as a starter kit. Unless of course your client wanted a website that was exactly like the Habitat (standard, legal or finance) websites. Even then, I wouldn't regard it as production ready.
Note that the readme file of the Habitat Repository clearly states it is not a starter ...
As asked in comments above; normally /bin files should not be locked for any particular reason (other than when the site is just starting up) - so I'm not entirely sure what's going on.
I can help you on the intermittent part of your question however; I would just flip the app pool before starting the file publish task.
appcmd recycle apppool /apppool.name
Although the Helix documentation does cover this, I guess it's a big pill to swallow all at once so here are a few simple guidelines to help you on the Helix path:
This acts as an API to Feature modules.
The Foundation does not contain any form of presentation!
This contains logic and presentation, but never styling.
TDS always serializes data from the root item, there are no settings that allow you to only serialise a part of a tree. Logically speaking, this makes a lot of sense for a Helix based solution where each project is self contained, independent and does not have any knowledge of other TDS projects in the solution. This means each feature is deployable in it's ...
We don't have a single package, but a package for each web project. Every web project has its publishing profile set to Web Deploy Package and the Package location is set to a unique zip filename in a common directory, e.g. ../Target/Feature-Navigation.zip.
The build server creates the packages with msbuild:
/t:build /p:PublishProfile=Release /p:...
Helix is just an software architecture pattern, it has nothing to do with how should be deployed. Your statement
Since by default Azure Web Apps needs VS to do the deployment
is not true. My adivce would be to create separate web deployment packages and deploy them using msdeploy, from your Release management solution, not directly from Visual Studio.
If you read the readme.md on the HelixBase github account, that seems to be exactly what it is for:
A Sitecore Helix based solution which can be used for Greenfield projects. Tackles some common problems when working with the platform.
However, you should only use if you agree with the fundamental architectural decisions made:
Are you going to use ...
You can put it to the Foundation layer. Any project in any layer can have references to the Foundation layer. Also, a Foundation project can have references to another Foundation project, but you need to follow this rule:
Unlike the Feature layer, there is no strict convention on dependencies between modules in the foundation layer. This means that one ...
You can make use of MVC Areas (support for which was introduced in Sitecore 8.1).
There are a number of strategies OOTB for resolving the area of a site, such as resolving by rendering parameters or layout definition. It's also possible to add your own strategy, we set your Area definition per site on the <site> node in using a similar processor as ...
TDS Classic 5.7 (released after this question was initially posted) now has a 'Sync all projects with Sitecore' feature. This is a context menu option on the solution (under the Team Development for Sitecore group) when you have TDS 5.7 installed, and allows you to run a sync across all TDS projects in the solution.
That blog post from Alan covers the scenarios nicely. The problem is that you are looking for Feature to Feature dependencies and if you follow Helix guidelines, that is expressly forbidden:
A strict awareness of dependencies within the Feature layer is very important. One Feature module must never depend on another Feature module
ref: Helix Feature ...
I would say it all depends on the complexity of your domain. If the amount of business logic and 3-rd party integrations is low, it might be enough to keep the code in the appropriate Feature/Foundation module, as Mark has mentioned above.
However, if you have a complex domain (e.g you are building some enterprise-level project), where amount of bussiness ...
What you want to do is take advantage of Sitecore's branching functionality. A branch in Sitecore is basically a prebuilt item tree that will be copied and inserted where you want it. It could be one item or a thousand items.
In your case, what it helps you do is to build out a page, with all the related data folders under the page. All delivered in an ...
As mention in @Anicho's comment, you should start by looking at helix.sitecore.net to get you started with understanding the modular architecture pattern and principles that Habitat was built around.
The Helix documentation will link you to the various OOD and SOLID principles on which the structure is based. Be sure to read them, as you will not be able ...
You're going about it wrong. Or - I should say - not in accordance with Helix principles.
First and foremost, your idea of a common base template to be used on all websites is not recommended practice.
What Helix Documentation States
The architecture does not have the concept of a single common base
template across all templates – which is a practice ...
I'm also going through the Professional Sitecore 8 Development book and ran into the same issue. Not sure if you found the fix but thought I'd share my findings. I'm using Visual Studio 2017 Professional (toolsVersion = 15) and it turns out that gulp-msbuild doesn't support VS 2017. I made the following edits to the gulp-msbuild files to make this work:
Others have recommended that you hold off, which is good advice. However, this is how I would start to go about doing it anyway if I had to.
First off, you need a plan. Just diving right in would be dangerous. Instead, I would first perform an audit of the codebase. If you haven't already, read through the Helix guidelines pretty carefully.
When I was setting up our project layer based upon the Helix architecture principles for the project layer, this bit stood out to me:
Typically, in a single tenant solution there will only be a single module, namely the specific website or requirements that fits the needs of the tenant, and this will contain little or no pre-compiled code but instead ...
You need to specify a template in the Datasource Template field of your controller rendering. This is the field that tells Sitecore to prompt an editor to select a data source when adding a rendering.
A cool feature
Sitecore will take template inheritance into account when allowing you to select data sources, which means that you'll be able to ...
I think it really depends on your module. So this question could be quite broad.
My high level thoughts would be:
Modules that are really CMS based. So a control panel, some admin interface etc...
Modules that are for presentation but are not a self contained feature, like the Sitecore.React module
Look at the category you are going to add ...
I wrote a blog post on this here - here are the cliff notes.
I'm going to assume Sitecore 8.2 for the version here, but the process is pretty much the same for earlier versions too, there would be some small tweaks.
Registering your own IoC Container
If you want to use your own container with 8.2 instead of the Sitecore out of the box one, or if this is ...
This is done in accordance with helix architectural principles. It states:
Avoid statically binding renderings in sub-layouts, but rather bind
all renderings to layouts via layout definitions and placeholders.
Static binding will make the page and solution structure less flexible
and introduces multiple maintenance methodologies. Although you might