Kentico Cloud Boilerplate for ASP.NET Core MVC

This boilerplate includes a set of features and best practices to kick off your website development with Kentico Cloud smoothly.

What's included

• Kentico Delivery SDK
  • Sample generated strongly-typed models
  • Sample link resolver
• Simple fixed-time caching
• HTTP Status codes handling (404, 500, ...)
• Sitemap.xml generator
• URL Rewriting examples
  • 301 URL Rewriting
  • www -> non-www redirection
• Configs for Dev and Production environment
• robots.txt
• Logging
• Unit tests (xUnit)

Quick start

Prerequisites

Required: You must have the latest version (.net core 2 is minimal) of the dotnet tooling installed. It comes with Visual Studio 2017 or you can download it with the .NET Core SDK.

Optional:

• Visual Studio 2017 for full experience
• or Visual Studio Code

Installation from NuGet

1. Open Developer Command Prompt for VS 2017
2. Run dotnet new --install "KenticoCloud.CloudBoilerplateNet::*" to install the boilerplate to your machine
3. Wait for the command to finish (it may take a minute or two)
4. Run dotnet new kentico-cloud-mvc --name "MyWebsite" [--output "<path>"]
5. Open in Visual Studio 2017/Code and Run

Installation from source

1. git clone https://github.com/Kentico/cloud-boilerplate-net.git
2. dotnet build
3. dotnet new -i artifacts/*.nupkg

How Tos

How to change Kentico Cloud Project ID and Delivery Preview API key

Kentico Cloud Project ID is stored inside appsettings.json file. This setting is automatically loaded using Options and configuration objects. You can also provide additional environment-specific configuration in appsettings.production.json and appsettings.development.json files.

For security reasons, Delivery Preview API key should be stored outside of the project tree. It's recommended to use Secret Manager to store sensitive data.

How to generate Strongly Typed Models for Content Types

With the new Delivery SDK, you can take advantage of code-first approach. To do that you have to instruct the SDK to use strongly-typed models. These models can be generated automatically by model generator utility. By convention, all Content Type Models are stored within the Models/ContentTypes folder. All generated classes are marked as partial which means that they can be extended in separate files. This should prevent losing custom code in case the models get regenerated.

If you want to use Display Templates (MVC), make sure you generate also a custom type provider (add the --withtypeprovider parameter when running the generator utility).

How to resolve links

Rich text elements in Kentico Cloud can contain links to other content items. It's up to a developer to decide how the links should be represented on a live site. Resolution logic can be adjusted in the CustomContentLinkUrlResolver. See the documentation for detailed info.

How to set up fixed-time caching

All content retrieved from Kentico Cloud is by default cached for five minutes. You can change the time by overriding the value of CacheTimeoutSeconds (e.g. in appsettings.json).

The CachedDeliveryClient class is a simple wrapper around the original https://github.com/Kentico/delivery-sdk-net/blob/master/KenticoCloud.Delivery/DeliveryClient.cs. It uses an https://docs.microsoft.com/en-us/aspnet/core/api/microsoft.extensions.caching.memory.imemorycache caching, currently implemented with the MemoryCache object.

The CachedDeliveryClient has the same methods as the original DeliveryClient. Upon invoking these methods, it stores the results into the in-memory cache, for the aforementioned amount of time.

As an in-memory caching mechanism, it is perfectly fine for non-load-balanced apps, or for apps configured with sticky sessions. For other scenarios, a distributed cache should be used instead.

Note: Speed of the Delivery/Preview API service is already tuned up because the service uses a geo-distributed CDN network for most of the types of requests. Therefore, the main advantage of caching in Kentico Cloud applications is not speed but lowering the amount of requests needed (See pricing for details).

How to adjust the sitemap.xml

The boilerplate contains a sample implementation of the SiteMapController. Make sure you specify desired content types in the Index() action method. Also, you can adjust the URL resolution logic in the GetPageUrl() method.

How to handle 404 errors or any other error

Error handling is setup by default. Any server exception or error response within 400-600 status code range is handled by ErrorController. By default, it's configured to display Not Found error page for 404 error and General Error for anything else.

How to adjust URL rewriting

The Boilerplate is configured to load all URL Rewriting rules from IISUrlRewrite.xml file. Add or modify existing rules to match your expected behavior. This is a good way to set up 301 Permanent redirects or www<->non-www redirects.

⚠️ ASP.NET Core 1.1 currently doesn't support Rewrite Maps, but there is a simple workaround for /oldUrl -> /newUrl mapping (see IISUrlRewrite.xml for example).

Feedback & Contributing

Any feedback is much appreciated. Check out the contributing to see the best places to file issues, start discussions and begin contributing.

Wall of Fame

We would like to express our thanks to the following people who contributed and made the project possible:

• Emmanuel Tissera - GetStarted
• Andy Thompson- GetStarted
• Sayed Ibrahim Hashimi - Microsoft
• Charith Sooriyaarachchi - 99X Technology
• Lex Li

Would you like to become a hero too? Pick an issue and send us a pull request!