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 (...
I don't really see any. Keep in mind that Habitat is just an example site that demonstrates the Helix principles. So really the requirement should be to build a Helix implementation on Sitecore 9.
Also they have a branch specific to Habitat for Sitecore 9: Sitecore 9 Branch of Habitat. So it might be beneficial to review that.
Some features that are ...
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 the ...
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 ...
Right click on your Solution tab and check the Project Dependencies. Ensure that the Build Order reflects the proper dependency order:
... and that in general, templates are pushed before their content. If need be, use the Dependencies tab to adjust project dependencies to adjust the build order.
Then, and only then, try a Build ...
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 ...
You need to change 2 things to get the gulp script to use v15.0 tools for MSBuild.
First, in the gulp.js file, you need to change everywhere you see this toolsVersion: 14.0 to toolsVersion: 15.0. There are multiple places in the file to change it.
Also, you need to make sure that the gulp-msbuild package is updated to the latest version to support build ...
Habitat is an example implementation of the Helix guidelines and shouldn't be used as a starter kit.
With that said, you should review what you will need now and remove what you can. It can always be brought back in at a later time if it's deemed appropriate.
Having taken the path of building a project using Habitat (in Sitecore 8.2, not 9) I can give you the following points:
Good example of how to structure a Helix solution.
Some useful Foundation modules which you could re-use. Some of these help you to adhere to helix guidelines such as the Multisite foundation module which includes a Datasource ...
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 Layer
I believe that the version you are looking for is Commit 1ab932d of the Hedgehog Development Fork For Sitecore 8.1 Initial (151003)
Release History of Habitat
I've taken a nose dive into both the Habitat and Hedgehog Fork's GitHub's. Please, if I have incorrectly listed a release or commit, please feel free to edit this answer.
Research of Hedgehog ...
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 ...
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 ...
There is a mismatch between your Sitecore binaries and Sitecore configuration.
The OnPackageInstallStartingRemoteHandler method was only added to PackagingEventHandler in Sitecore 8.2 Update 1. It didn't exist yet in 8.2 Initial Release. Which means you have 8.2 (or earlier) binaries with 8.2 Update 1 configuration.
What happens, most likely, is that you ...
You can publish a single project by right clicking on the project and selecting the Publish option in Visual Studio. Or if you have Click Once publishing toolbar open, you can select the project and publish by clicking the Publish Web button.
Typically I will use this process when I am working on a single project, vs waiting for all the projects to ...
This is controlled by the languageEmbedding attribute on your linkManager.
By default, Sitecore adds the language code to your URLs asNeeded. Which is a bit fuzzy; but essentially Sitecore should add it when it isn't sure of your current Context.Language and wants to make sure the URL points to the desired result.
Other options are:
Always (always enforce ...
Although this is off-topic, this is a common issue in Sitecore for those who are experimenting with Helix/Habitat. Anyway, you can also achieve this on the VS UI which essentially results to the project file snippet Anton has shown above. Just choose Properties on the file you want to not process and change the Build Action to None.
Make sure you have updated the Habitat.Dev.config and set the sourceFolder to the src directory of your habitat solution.
The default location is C:\Projects\Habitat and you would expect that to be the root directory of the repository, however that is not the folder the configuration wants. It is looking for the "src" directory.
If your root git folder is ...
The hostname should be habitat.dev.local on your Sim installation.
In the site definition you have:
<site name="habitat" patch:after="site[@name='modules_website']"
This is more of an opinion based question. But I will list the positives and negatives below. A lot of these depend on your preference. I have personally gone with both approaches, so I know that most
Positive/Negative of Static Bindings:
+ Less clutter in your Presentation Details.
+ Less work maintaining your Presentation Details.
- Less control: ...
You could also add a property group called ExcludeFilesFromDeployment to your profile.pubxml publishing profile. I have mine setup like this:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
If this is the first time you are installing then those warnings are fine to ignore. Those warnings are stating that those services could not be stopped/found because they wouldn't exist yet.
If you already had the site installed, the install script would stop the services so that new files could be installed over the top of them.
You can safely ignore ...
Looks like you're running a non-admin Powershell console. Try running it as an admin user.
If that is not an option, you may need to unblock the script. Locate it in File Explorer and Unblock it.
Further reference: Unable To Run Downloaded PowerShell Script
Edited to add.
If none of this works, you're likely getting an ExecutionPolicy from your AD. You ...
My two cents
If to go strictly after the Helix documentation it seems like both the workflows and the datasources should belong to the project layer:
So it would seem that there is a discrepancy between the Helix ...
After reading @jflheureux's answer and little bit digging around Habitat release package.
First Aha!, it is a Sitecore package definition file which contains everything - content items, security items, files. Second Aha!, we can Generate Package using Sitecore Rocks by using package.xml which is a similar process as Package Designer in Sitecore Desktop.
I believe the use of this package is internal to Sitecore employees who maintain and publish the demo on GitHub: https://github.com/Sitecore/Habitat/releases
They update the file, upload it to Sitecore, manually create a Sitecore package with it and upload that package to GitHub. Maybe they to the above automatically using custom CI tasks.
I have done some ...
In the SiteDefinition.config file each site should contain a hostName attribute. Sitecore will match the correct site based on the incoming url and matching hostName.
Check out the SDN page for hostName configuration for more information.
The real benefit is to allow your editors to change the header to meet their needs without needing a specific template. Example is a landing page for a campaign that requires a smaller header/menu. The editor could change out the header with a new header for that page specifically without requiring development to create a template for this single use.
It's basically a Node version issue. Assuming that you've downloaded the latest NodeJS and installed it (which means its location should be one of your system's environment variable PATH), just move up the $(PATH) location above the (DevEnvDir)|Extensions\Microsoft\Web Tools\External
Tools > Options > Projects and Solutions > External Web ...
It's just ensuring that the user has the default profile, because they are editing/reading/registrating the users with exactly the Default Profile.
You can see in the Sitecore.Feature.Accounts.Controllers.AccountsController.Register
public ActionResult Register(RegistrationInfo registrationInfo)