Deploy without the administration
Deployment without the Xperience by Kentico administration is currently not supported when deploying to SaaS. The scenario described on this page applies only to private cloud deployments.
Xperience and all related dependencies are installed via NuGet packages. The installed packages dictate the features available to each project. However, not all packages are required for Xperience sites to run in production environments.
The Xperience administration interface (installed via the Kentico.Xperience.Admin NuGet package) and all related customizations can be removed when publishing to production. In these types of environments, you can have:
- One Xperience instance with the administration interface. Access to this instance is restricted only to authorized users (i.e., placed behind a firewall or on a private network). This is where content editors and other users work with the system.
- Another Xperience instance without the administration interface. This is the instance with which regular live site visitors interact.
- Both instances connect to the same database.
Advantages |
|
Disadvantages |
|
In the most basic scenario, you can set up and deploy Xperience without the administration manually:
- Create a separate copy of your Xperience application.
- Uninstall the Kentico.Xperience.Admin NuGet package and remove any custom code intended only for the administration.
- Deploy both applications – the original to an environment with restricted access and the new copy without the administration to production.
However, in most cases, we recommend that you integrate the separation into an automated publishing script or pipeline.
Sample automated separation process
This section outlines an approach that modifies the application’s build process to remove the Kentico.Xperience.Admin NuGet package and all related dependencies, including custom code intended only for the administration. The demonstrated approach is suitable for use in publishing scripts or automation pipelines.
Edit your Xperience application’s .csproj file and add a new
AdminAttached
MSBuild property:XMLXperience application's .csproj file<PropertyGroup> <TargetFramework> <!-- ... --> </TargetFramework> <RootNamespace> <!-- ... --> </RootNamespace> <!-- Defines an MSBuild property that defaults to true if not explicitly passed to MSBuild as a parameter --> <AdminAttached Condition="'$(AdminAttached)' == ''">true</AdminAttached> </PropertyGroup>
Add the following condition to the
Kentico.Xperience.AspNetCore.Admin
package reference using theCondition
attribute:XMLXperience application's .csproj file<ItemGroup> ... <!-- If the specified condition evaluates to true (true by default), the project maintains this package reference --> <PackageReference Include="kentico.xperience.admin" Version="..." Condition="'$(AdminAttached)' == 'true'" /> </ItemGroup>
Follow a similar process to remove any custom code when customizing the administration interface or some of its components. Assuming your code follows best practices for admin UI customization outlined in Admin UI customization model overview, your administration-related code is located in isolated assemblies/NuGet packages, making the process straightforward. Repeatedly add the
Condition
attribute to all relevant references:XMLXperience application's .csproj file<!-- Project assembly references --> <ItemGroup> ... <ProjectReference Include="..\Acme.Web.AdminCustomCode.csproj" Condition="'$(AdminAttached)' == 'true'" /> </ItemGroup> <!-- Project package references --> <ItemGroup> ... <PackageReference Include="Emca.Web.AdminCustomCode" Version="..." Condition="'$(AdminAttached)' == 'true'" /> </ItemGroup>
If you also need to make specific code outside dedicated assemblies run only when the administration is attached, declare a conditional compilation constant and use it as required:
XMLXperience application's .csproj file<PropertyGroup Condition="'$(AdminAttached)' == 'true'"> <DefineConstants>$(DefineConstants);ADMIN_ATTACHED</DefineConstants> </PropertyGroup>
C#ADMIN_ATTACHED usage#if ADMIN_ATTACHED // Surrounded code only compiles when administration dependencies are present #endif
You can also invert this condition to run code only when the administration is detached.
When you need to publish the project without admin UI packages and dependencies, pass
AdminAttached=false
as a parameter to MSBuild:CMDdotnet publish -c Release -p:AdminAttached=false --output <OUTPUT_DIRECTORY>
The output directory now contains the published application minus the dependencies marked by the AdminAttached
condition.