Great news if you’re starting a new Sitecore 10 project – you can use Constellation version 10.0.X NuGet packages in your solution.
If you’ve used Constellation with Sitecore 9.1 projects, you might notice a few changes based on updates in 9.2, 9.3 and 10.0.
Adjusted to use the new LinkBuilder API rather than the LinkProvider API directly. Now uses LinkBuilderOptions rather than LinkOptions to construct URLs. Note that this actually has no effect on the way you configure LinkProviders for each site in your install – it’s just an API change.
Constellation Configuration Files
Previously all Constellation *.config files were stored in /App_Config/Include/Constellation. To better serve Sitecore’s Configuration Layers topology, Constellation configuration files have been moved to the ..Include/Foundation and ..Include/Feature folders. This was done to ensure that Constellation configuration files perform their overrides at the correct layer during startup. As usual, the default Constellation configuration files should be considered read only. Use patch files to change behavior. I recommend patching at the Project layer.
Sitecore 10 has changed a few of the default minimums for some core .NET tech:
- ASP.NET MVC must be set to 5.2.4
- .NET Framework must be set to 4.8
All Constellation libraries have been triple checked to make sure you don’t get into DLL hell when you install these packages. When in doubt, Constellation always defers to the versions Sitecore is using.
Over the last 4 years Constellation had gotten a little cluttered with NuGet dependencies imported as a result of adding Sitecore NuGet packages to the Constellation solution. Everything has been gone through to make sure Constellation does not import anything more than it absolutely has to. References to Microsoft Enterprise libraries and Lucene have been removed because they are not necessary to support development on Sitecore 10.
Support for the new Developer Experience
Constellation NuGet packages were not designed to be used with .NET Core solutions. The new Sitecore development experience (which is purely optional) has a completely different API, and is focused solely on the presentation layer. Since Constellation includes a lot of MVC syntax candy, most of it is not well suited for the new .NET Core Rendering Host. Specific libraries are discussed below.
.NET Core Incompatible Libraries
The following libraries require Sitecore.Data.Items, Sitecore.ContentSearch, the HttpRequestPipelines, and/or ASP.NET Modules, which do not exist in the new .NET Core rendering host:
The following libraries feature information architecture and item management components that have value if they are installed into the Sitecore CM instance. Any Rendering features will have to be developed from scratch for .NET Core:
Bottom line: You absolutely can use Constellation with Sitecore 10.
If you are going to do traditional Sitecore ASP.NET MVC development – Constellation provides you with significant advantages over stock Sitecore programming and should improve your time to value.
If you’re going to use the .NET Core Rendering Host, you can absolutely install Constellation on your CM server. (See guidance above.) This will give you some badly needed Information Architecture and help control the content author experience.
For the presentation layer you’ll need to “go native” for your presentation layer. Considering that Constellation’s MVC components were expressedly designed to make programming Sitecore MVC a less tedious and error-prone process, you will likely find that the new .NET Core Rendering Host’s APIs feel “familiar” – particularly the way Items are modelled.
In theory, if your Sitecore installation included a mix of MVC and .NET Core sites, you could absolutely use Constellation side-by-side with the new Rendering Host, in much the same way that Constellation will respect the boundaries of JSS or SXA websites within a single Sitecore solution.