The system allows you to transfer custom modules to other instances of Kentico using NuGet packages.
When creating modules that you wish to deploy as installation packages, you need to take additional steps during the development process. The module must be represented by a separate web application project inside the Kentico solution. Based on conventions, the installation package automatically includes files from specific folders and database objects related to the module.
The module project only exists on the Kentico instance that you use to develop the module. When you install the module on a different instance, all code (including code behinds of web forms and controls) is compiled inside the module DLL, and other files are integrated into the main Kentico project. Installation of modules is supported for both web application and web site type projects.
Module packages do not include any data stored in module classes. If you wish to provide default data along with your module, you can prepare additional export packages containing the data or an SQL script that creates the required data after the installation of the module.
Modules transferred via installation packages currently have the following limitations:
To install module packages, you need to open the target project in Visual Studio – the installation cannot be performed on certain types of deployed and running websites (for example on Microsoft Azure).
You cannot use installation packages to transfer modules for development on other instances – the module always becomes sealed and uncustomizable after installation, and all code is compiled into a DLL. If you wish to develop the module on multiple instances, you need to manually transfer the module’s files and database objects.
The system has very limited support for uninstalling or updating modules installed from packages.
You cannot define dependencies between multiple module packages.
You cannot easily use components (user controls etc.) from the main Kentico project inside the module’s project. This may make it difficult to develop custom web forms, user controls or web parts within packageable modules.
You cannot create installation packages for:
- The default Kentico modules.
- The default Custom module, which is intended for non-transferable customizations.
- Modules installed from other installation packages.
To create an installation package for a custom module, you need to:
- Create a separate project for the module in the Kentico solution
- Develop the module (see Example - Creating a packageable module for an example)
- Make sure the installation package includes database objects related to the module
- Optional steps:
- Create the module installation package
Creating the module project
We strongly recommend using web application installations of Kentico when developing custom modules that you wish to deploy as installation packages.
Module projects always use the web application format – having the same project type for the main Kentico project makes it easier to reuse files. With web site projects, you need to manually ensure that all module files are converted to the web application format.
Before you can develop a module that supports the creation of installation packages, you need to prepare a web application project and include this project in the Kentico solution.
The following steps are necessary to maintain the proper folder structure within the Kentico solution:
- Create the project
- Copy the project files to the Kentico solution
- Include the project in the Kentico solution
Creating the project
- Open Visual Studio and create a new web application project.
- Important: The project name must match the module’s code name.
- Select the ASP.NET Empty Web Application project template (in Visual Studio 2013, available in the Visual C# -> Web -> Visual Studio 2012 template category).
- Delete the project’s Web.config file.
- In the project’s Properties folder, rename the AssemblyInfo.cs file to <project name>AssemblyInfo.cs.
- Save the project.
Copying the project files to the Kentico solution
Open the project’s folder on your file system.
Edit the <project name>.csproj file and make sure the content reflects the change in the name of the AssemblyInfo.cs file.
<Compile Include="Properties\<project name>AssemblyInfo.cs" />
Copy the <project name>.csproj file to the CMS folder of your Kentico web project.
Copy <project name>AssemblyInfo.cs from the project’s Properties directory to the CMS\Properties folder of your Kentico web project.
Including the project in the Kentico solution
Open your Kentico solution in Visual Studio (using the WebApp.sln file).
Add your custom module project to the Kentico solution:
- In the Solution Explorer, right-click the solution.
- Click Add -> Existing Project…
- Select the <project name>.csproj file in the project’s CMS folder.
Add the required references to your custom module project:
- Right-click the project and select Add -> Reference.
- Open the Browse tab of the Reference manager dialog, click Browse and navigate to the Lib folder of your Kentico web project.
- Add a reference to the CMS.Core.dll library (and any others that you require for custom code).
Expand the Properties folder of the module project and edit <project name>AssemblyInfo.cs.
Add the AssemblyDiscoverable assembly attribute:
using CMS; [assembly:AssemblyDiscoverable]
Save the solution and all files.
The Kentico solution now contains a web application project representing your custom module. You can start developing the module. After you compile the module code into an assembly (i.e. build the project), the system automatically includes the resulting DLL when you create an installation package for the module.
The additional project only exists on the Kentico instance that you use to develop the module. When you install the module on a different instance, all code is already compiled inside the module’s DLL and other files are integrated into the main Kentico project.
Note: If you ever need to rename a module during development, Clean your solution in Visual Studio before you rename the module project or manually delete the original DLL. Otherwise the module’s old DLL may cause errors on your site.
Including database objects in the package
When creating module installation packages, the system automatically includes the following database objects that are directly related to the given module:
- UI elements
- Setting categories and groups, including all contained setting keys
Adding additional libraries to the package
The system cannot automatically identify all dynamic link libraries (DLLs) required by your custom module. If your module uses third-party or custom libraries, you need to assign these libraries to the module before creating the installation package.
Open the Modules application and Edit () your custom module.
Switch to the Additional libraries tab.
Assign any number of libraries from the project’s bin folder:
- Click Add library.
- Select the library that you wish to include in the module’s installation package.
- Click Select.
When you create the module installation package, the package also contains the selected libraries.
Note: Do NOT assign DLLs that are part of the default Kentico project as additional libraries of module packages. This includes any DLL files in the CMS\bin or CMS\CMSDependencies folders of unmodified Kentico projects. Adding these libraries may cause the system to work incorrectly after installing the custom module package.
Configuring custom module settings
If you have defined custom settings for the module, we recommend configuring the default values of the settings before you create the installation package. Open the Settings application and set the desired (global) values for the module’s settings.
The setting values configured on the development instance are used by default when the module is installed on other instances of Kentico.
Preparing additional SQL scripts for the installation
Installation packages cannot automatically transfer certain types of database components, such as indexes and views. If you wish to deliver such components with the module, you need to manually prepare SQL scripts that create the required database objects.
Add the script files into the development project’s ~/App_Data/CMSModules/<module code name>/Install/ folder (create the folder if necessary). The script files must be named either before.sql or after.sql (intended to run before or after importing the module’s database objects respectively).
The system automatically includes the script files into the module’s installation packages. When installing the module, users need to run the before.sql and after.sql scripts against their database.
Creating the module installation package
Once your custom module is fully developed, you can create the installation package in the Kentico administration interface:
Open the Modules application and Edit () your custom module.
On the General tab, fill in the module’s metadata:
Module description (Default value: No description provided)
Module version (Default value: 1.0.0)
Module author (Default value: Unknown)
The system saves the values into the metadata of the module’s installation packages. If not specified, the package contains the default values.
Click Create installation package.
- The system opens a dialog showing the package’s metadata, and the files and objects included in the package.
The system creates the module installation package in the project’s export folder (CMS\CMSSiteUtils\Export by default). You can use the package to install the module on other instances of Kentico.
Kentico version requirements of module packages
Module packages can be successfully installed only on Kentico instances that have the same version as the source instance, including minor hotfix versions. For example, if you create a module installation package on a 8.2.16 instance, users cannot install the package on Kentico 8.2.15 or older. We strongly recommend adding information about the minimum required Kentico version into the Module description.
Module packages from older versions can be installed on newer versions, but may cause problems or errors depending on the differences in the data structure and API of the two versions.
Reference - Custom module conventions
To ensure that the installation packages created for your custom modules contain the required files and database objects, you need to follow naming and location conventions.
Module code name
The naming conventions for folders, files and database objects are based on the Module code name, including any prefixes or namespaces. For example: Acme.Forums
Carefully consider the code name when creating custom modules. Choose a sufficiently unique module code name to avoid collisions with the default Kentico modules or other custom modules. Do NOT start the code names of custom modules with the cms. prefix, which is reserved for Kentico modules.
File system conventions
Include all custom files related to your module into the module’s web application project in Visual Studio, NOT the default Kentico web project (CMSApp).
Both projects share the same folder on the file system, so you can include files located in the default Kentico folders (such as ~/App_Data/CMSModules or ~/CMSWebParts) without problems. When the module package is installed on a different instance, files from both projects are merged into the standard Kentico project.
Including files in the module project ensures that:
- Custom module files are clearly separated in your development solution from the default files.
- All required code is compiled into the module’s DLL. Module installation packages transfer all code within the module DLL, without the original code files. Files with separate code behinds (web forms, user controls, web parts, form controls, handlers, etc.) are installed without the code behind and instead reference the appropriate class in the module DLL.
The library containing the module’s compiled code must be located in the ~/bin folder of the Kentico project and have the same name as the module code name. For example, the Acme.Forums module has the Acme.Forums.dll library.
As long as the module’s web application project in the Kentico solution matches the module name, the library is created automatically when you compile the project.
3rd party libraries
You can manually include 3rd party libraries into the module’s installation package using the administration interface. The libraries must be located in the ~/bin folder of the Kentico project.
All code files must be included in the module’s web application project in Visual Studio. Examples of module code files are:
We recommend organizing the code files inside a folder that matches the code name of the module, for example: ~/Acme.Forums/
Web forms and controls
Place web forms or user controls used by your module into the ~/CMSModules/<module code name>/ folder.
Web part files
Place the source files (user controls) of web parts that are part of your module into the ~/CMSWebParts/<module code name>/ folder.
For example: ~/CMSWebParts/Acme.Forums/
Form control files
Place the source files (user controls) of form controls that are part of your module into the ~/CMSFormControls/<module code name>/ folder.
For example: ~/CMSFormControls/Acme.Forums/
Place the XML definitions for the module’s UniGrid components (object listings) into the ~/App_Data/CMSModules/<module code name>/UI/Grids/ folder.
The default recommended location includes further subfolders named after specific object types. For example: ~/App_Data/CMSModules/Acme.Forums/UI/Grids/Acme_Forums_Forum/default.xml
Place the module’s resource strings into resource files (.resx) inside the ~/CMSResources/<module code name>/ folder. To add resource files for specific languages, create subfolders with names that match the required culture code.
For example, ~/CMSResources/Acme.Forums/Common.resx for strings in the default culture, and ~/CMSResources/Acme.Forums/<language code>/Common.resx for the <culture code> culture.
Note: If you plan to publish your development project, set the Build Action property of resource files to Content to ensure that they are included. The Build Action of resx files must also be set manually on other instances after installing the module package.
For example: ~/CMSScripts/CMSModules/Acme.Forums/TextBox.js
If your module uses physical CSS files, place them into the ~/CMSModules/<module code name>/Content/ folder.
For example: ~/CMSModules/<module code name>/Content/Forums.css
To add links to module stylesheets on pages, call the following methods (in the code behind of pages or components such as form controls):
The CSSHelper class requires a reference to the CMS.Helpers namespace.
If your module uses HTTP handlers or other types of system pages, place them into the ~/CMSModules/<module code name>/CMSPages/ folder.
For example: ~/CMSModules/Acme.Forums/CMSPages/GetAttachmentHandler.ashx
Conventions for database objects
The code names of web parts must start with the <module code name>. prefix (including the dot character).
For example: Acme.Forums.ForumList
Module installation packages automatically include the parent categories of web parts that match the naming convention.
The code names of form controls must start with the <module code name>. prefix (including the dot character).
For example: Acme.Forums.TextBox