Kentico CMS provides a great utility for the installation and management of sites, called the Kentico Installation Manager (KIM). With this utility, you can quickly create new sites, download the latest hotfixes / upgrades, and manage your Kentico installations. While the Kentico Developer’s Guide does a great job of overviewing the utility, I wanted to dive a little deeper and give my thoughts on the site creation process. For this guide, I will be creating a .NET 4.5/VS 2012 site to run on local IIS and choosing a custom installation.
1. Installing your site
The first step is to create your actual Kentico site. What this step does is copy all of the Kentico source files to your directory (or server) that will be necessary to run the application. Open the KIM and click the “Install” button.
2. “Select installation mode”
With Kentico v7, Kentico introduced the option of “default” settings when creating a site. This option selects common installation options to simplify the process for the developers. The default settings include:
- IIS Virtual Directory (KenticoCMS7)
- .NET 3.5
- “Full” Installation- including all modules / templates
This is a great option if you want to create a site quickly. It does however, target the 3.5 framework so choose wisely (says the Holy Grail Knight…)
For this guide, I will choose the “Advanced Options” to allow for more customization. This option allows for much more customization and configuration, as explained below.
3. “Select .NET Framework version”
In a “Custom Installation”, users can select the .NET Framework and project type for the site. This option will determine the framework the site will sue, as well as the type of Visual Studio project to deploy.
“.NET Framework version”
This setting allows you to set which .NET framework you want to target. Kentico supports 3.5, 4.0, and now 4.5 frameworks. Additionally, the installation creates a project targeted at the respective Visual Studio version. Choose the option that best fits your hosting environment and application.
Prior to v6, Kentico always created a “web site” project when making a site. Those familiar with .NET may recognize this project type from the early days of VS development. For that that don’t know, a web site is an un-compiled site, in which you deploy the business layer (.cs code-behind files) along with the presentation layer (.aspx files). This type of project allows for very rapid development in that only the actual page (or code behind) that needs updating can be deployed without re-deploying the entire site. One of the downsides to this is that you deploy all of your code with the site, creating a potential security vulnerability.
With v6, Kentico introduced the “web application” project type. In this project, all business logic is pre-compiled and deployed as dll(s) with the presentation layer. The web application project has a number of options, but just note that you have to redeploy the entire site (if you compile into a single DLL) every time any code is changed. This type of project is a little more secure in that all of you logic is compiled ahead of time and not viewable on the server. Web applications can also be configured to compile the presentation layer (.ASPX) into the dlls for further security.
The “Windows Azure project” option is a “web application” that includes the necessary role definitions to run in Windows Azure. This project type has the base site (as a web application), an Azure web role for running the application, and an Azure Worker role for Windows Azure Storage integration and background processing. Only use this option if you will be deploying your site to Windows Azure.
Microsoft has a decent blog on explaining the differences in project types and when you would want to use which. http://msdn.microsoft.com/en-us/library/dd547590(v=VS.100).aspx
4. “Select target location”
This setting is determined by where you want to run the actual site. Each option will attempt to deploy the site in a different configuration so choose the option that best suits your environment.
“I want to use local IIS server”
This setting will use the local IIS server and create a virtual directory for the application. The KIM will create a folder for the site, deploy the files to it, and then create a virtual directory within the local IIS for the site to run. Typically, I develop sites locally and then deploy to my hosting server. I choose “local IIS server” to mimic the hosting server for that reason.
“I want to use built-in web server in Visual Studio XX)”
This option is ideal if the machine you are developing on does not have IIS installed. This project will be configured to use the built-in web server within Visual Studio to run the application. This is a good option if you aren’t experienced with IIS and virtual directories and just want to develop and run the site in the simplest configuration.
“I want to install Kentico CMS on a remote (production or testing) server”
This option works well if you will be developing the site on a remote server. The KIM will attempt to connect to the specified server and create the folder to deploy the site to. You will need to access that server to configured IIS and the app pool after the installation is complete. The appropriate network connections / permissions will need to in place to allow the KIM to connect to the remote machine.
“I want to modify an existing Kentico CMS Installation”
This option is if you want to add features to an existing installation. An existing site can have features added / removed right from the KIMK to simplify the process. Typically, we will limit the modules installed on some sites to limit the footprint / file count. This option allows us to add those modules at a later date with recreating the entire site.
5. Setting Local IIS (Only if using the “local IIS option)
When selecting local IIS, this is where you specify the web site / type app pool / target folder to the deploy the site to. There are several options here and each on will affect how the site is deployed onto the machine. Choose the appropriate options for your environment.
If you system is running multiple sites, you can choose the desired site to create the virtual directory under. You can choose any site currently on your machine, if you are running multiple sites.
“Type of application pool:”
This setting allows you specify if you want the app pool for the site to run in “Integrated” or “Classic” mode. Legacy sites / functionality often require the “Classic” setting so set accordingly.
“Choose target folder:”
This is the folder that the KIM will copy the web site source files to.
“this is an installation in the root”
This checkbox tells Kentico to NOT create a virtual directory and install it into the root folder of the chosen website. Typically, on a development server you will not choose this, unless you set up a separate in IIS for each site you develop.
6. “Creating the virtual directory”
If you kept the default settings, the KIM will attempt to create the virtual directory underneath the chosen site.
7. “Select Installation Type”
This step is where you select the features / modules / templates to include within your site. You can choose “Full” installation to enable every feature, or “Custom Installation” to select specific items. The “Full” installation is easiest as it includes every bit of Kentico functionality, but also increases the footprint of the application on the server. The “Custom” option is great for removing unnecessary features and UI cultures.
“Register performance counters for Health Monitoring”
Kentico can be installed with counters to report on the health and performance of the site. This option will registers the Performance counters within Windows for Kentico to report to.
“Install Windows services for Scheduler and Health Monitoring”
This option installs the necessary services on the local machine to collect and report the health stats for the installation.
The Kentico Developer’s Guide has more details on the services here.
8. “Select Components"
When choosing “Custom Installation”, use the following screen to select the features to include within the site. Often, you may want to remove the web site templates, UI Cultures, and other unnecessary modules / features if you know your site will never use them. Removing items will reduce the amount of files within your project.
We tend to leave the modules included to simplify development if the client want sot add those features in the future. We do remove the “web templates”, “UI Cultures” and “Spell Check” dictionaries for any languages we can’t understand.
You can click “Deselect all” to create a completely “bare minimum” site to further reduce the amount of files deployed.
9. “Copy files”
The KIM will now create the site folder using the options you selected. Behind the scenes, it will create the folder in the “Target Folder” you entered and copy the actual source files to the new location. This process may take a few minutes, depending on what options / features you selected. After clicking, sit back and enjoy the parade of messages about copying the KIM has to offer. Perhaps make a special night out of it and dress up nice and fix your hair real classy. The possibilities are endless…
10. “Installation Finished”
Once the installation is complete, the utility will display a link to access the site and continue the site creation process. The new site will guide you through the creation of the database and actual setting up of a site (if using a template).
Before clicking, be sure to set your appropriate security permission to ensure the site will function properly. You can find more info on folder permissions here.
Now that the site is created, it will be listed in the KIM. The KIM will display the current version, hotfix version, registered date, and path. This is a great way to keep track of all of your projects and quickly identify what hotfixes have been applied.
Hopefully this guide explains a little bit about the KIM and how it manages sites. The utility has a ton more features that I’ll try and cover in future blogs. Feel free to let me know if you have any other tips!