Sitecore 9 is a complex beast, and much changed from version 8. Where before the application used to be a fairly monolithic Web Application, the big difference with version 9 is that the multiple roles that the application serves has been broken out potentially into multiple applications. This means that powershell is now required to organise the complex process of setting up a local Sitecore instance.
Sitecore 9 is installed using the Sitecore Installation Foundation (SIF) and some customisation of powershell parameters The SIF uses msdeploy to create the websites, and SQL and DAC Fx to create the databases that power them.
There is a common issue with the SIF, which is known and has a knowledgebase fix: https://kb.sitecore.net/articles/019579, but unfortunately this fix does detail why it might work (or in fact why not).
The installation process uses msdeploy, DacFx and SQL server to create the required databases, the installation can fail with the following (or similar) message:
[WebDeploy]:[Path] C:Program FilesiisMicrosoft Web Deploy V3msdeploy.exe msdeploy.exe : Error Code: ERROR_DACFX_NEEDED_FOR_SQL_PROVIDER At C:Program FilesWindowsPowerShellModulesSitecoreInstallFramework1.2.0PublicTasksInvoke-CommandTask.ps1:31 char:13 + & $Path $Arguments | Out-Default + ~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (Error Code: ERR...OR_SQL_PROVIDER:String) , RemoteException + FullyQualifiedErrorId : NativeCommandError More Information: The SQL provider cannot run with dacpac option because of a missing dependency. Please make sure that DacFx is installed. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_DACFX_NEEDED_FOR_SQL_PROVIDER. Error count: 1. Install-SitecoreConfiguration : Command C:Program FilesiisMicrosoft Web Deploy V3msdeploy.exe returned a non-zero exit code - (-1) At D:Sitecore9installinstallSitecore9.ps1:45 char:1 + Install-SitecoreConfiguration @xconnectParams + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Install-SitecoreConfiguration [TIME] 00:00:22 Transcript stopped, output file is C:WINDOWSsystem32xconnect-xp0.180409 (5).log Invoke-CommandTask : Command C:Program FilesiisMicrosoft Web Deploy V3msdeploy.exe returned a non-zero exit code - (-1) At C:Program FilesWindowsPowerShellModulesSitecoreInstallFramework1.2.0PublicTasksInvoke-WebDeployTask.ps1:36 char:2 + Invoke-CommandTask -Path $Path -Arguments $msdeployArgs -TaskName ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException + FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Invoke-CommandTask
The problem is a failure to identify the DacFx components or dependencies, which begs the question:
“how can MsDeploy not find the Dac components, as the machine has the Dac components installed?”
The fix from Sitecore suggested putting explicit registry settings pointing to the Dac components and dependencies, and re-installing MsDeploy. This may not work however if multiple versions of SQL and DacFx are installed on the machine (as is common for developer machines).
Clearly, the dependencies being pointed to need to match those that msdeploy expects to use, so the question is: “What version of the Dac components is MsDeploy trying to use, and why can’t it find it?”
Eventually, I found this registry key:
ComputerHKEY_LOCAL_MACHINESOFTWAREMicrosoftMicrosoft SQL ServerDACFrameworkCurrentVersion which governs the Dac components loaded.
This key will tell MsDeploy which Dac version components to use (regardless of what version of SQL or Dac are installed), and so even if you have more up to date components that are installed, the missing dependency pertains to the specific version pointed to in that registry key.
In order to fix this problem, the following needs to be true:
1.) The version of the Dac pointed to must be installed
2.) The Dac components (and dependencies) need to be registered using gacutil. To do this for SQL Server 2016 (v 130):
cd “C:Program Files (x86)Microsoft SDKsWindowsv8.0AbinNETFX 4.0 Tools”
gacutil -i “C:Program Files (x86)Microsoft SQL Server130DACbinMicrosoft.SqlServer.Dac.dll” -f
gacutil -i “C:Program Files (x86)Microsoft SQL Server130DACbinMicrosoft.SqlServer.Dac.Extensions.dll” -f
gacutil -i “C:Program Files (x86)Microsoft SQL Server130DACbinMicrosoft.SqlServer.Types.dll” -f
gacutil -i “C:Program Files (x86)Microsoft SQL Server130DACbinMicrosoft.SqlServer.TransactSql.ScriptDom.dll” -f
gacutil -i “C:Program Files (x86)Microsoft SQL Server130DACbinMicrosoft.Data.Tools.Schema.Sql.dll” -f
gacutil -i “C:Program Files (x86)Microsoft SQL Server130DACbinMicrosoft.Data.Tools.Utilities.dll” -f
NB. The path referenced in the registry for the DacFX components and their dependencies must be where the componentts that are registered with the GAC actually are. If the GAC contains another version of an assembly that is is a directory that is different for the DacFxPath or the DacFxDependenciesPath, it will NOT work.
3.) The DacFxPath and DaxFxDependenciesPath in ComputerHKEY_LOCAL_MACHINESOFTWAREMicrosoftIIS ExtensionsMSDeploy3 should point to the Dac version being targeted, i.e. C:Program Files (x86)Microsoft SQL Server130DACbin
for v 130.
4.) The minimum version of the Dac that can be used is v130 (SQL Server 2016), because the dacpac being used is v130 and so will fail if an older version of DacFx is used.
Having fixed all the above, The database part of the installation completed without error.