This boilerplate includes a set of features and best practices to kick off your website development with Kentico Cloud smoothly.
- Kentico Delivery SDK
- 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)
Required: You must have the latest version 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
- Open Developer Command Prompt for VS 2017
- Run
dotnet new --install "KenticoCloud.CloudBoilerplateNet::*"to install the boilerplate to your machine - Wait for the command to finish (it may take a minute or two)
- Run
dotnet new kentico-cloud-mvc --name "MyWebsite" [--output "<path>"] - Open in Visual Studio 2017/Code and Run
git clone https://github.com/Kentico/cloud-boilerplate-net.gitdotnet builddotnet new -i artifacts/*.nupkg
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.
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).
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.
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).
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.
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.
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.
/oldUrl -> /newUrl mapping (see IISUrlRewrite.xml for example).
Any feedback is much appreciated. Check out the contributing to see the best places to file issues, start discussions and begin contributing.
We would like to express our thanks to the following people who contributed and made the project possible:
Would you like to become a hero too? Pick an issue and send us a pull request!