In this tutorial, you will learn about some essential developer tweaks that I recommend you make within your Umbraco V9 project. All the tips listed in this guide are aimed at ASP.NET Core. One of the reasons I write these tutorials and create videos is to help people become better craftspeople. There is a big difference between writing clean, well-crafted code compared to cranking out an old shit. These tips will help ensure your Umbraco v9 codebase is written in a way that will make it easy for multiple people to work on a project while avoiding areas where code rot can occur. If you want to ensure that your v9 project is written to a high standard, read on 🔥🔥🔥
Setting Local Developer Connection String
Most of the projects I work on involve a team of developers. Each developer will require a different connection string for their local database to work. In order to reduce project start-up friction on my projects, I will make sure that it is super simple, quick and easy for someone new to get set up on one of my projects. There are a few ways to solve this issue, which one should you use?
The solution I recommend you adopt to solve this issue is based on creating a separate config file per developer. Using the developer's machine name, you can define a custom config file per person easily. The good thing about this approach is that all your config files can be checked into source control. I personally prefer this, compared to making everyone create a config file that never gets checked in and can be easy to delete when doing a git clean -f or a git reset --hard. Following this approach, you will add config files like the example below:
IMAGE
Within your project, you will need to add some configuration to load this config file. This code can be added within program.cs. Within here, you can add this config:
This will tell the program to load the normal appsettings.json'. If a config file is found that has a matching prefix (based onEnvironment.MachineName`) override these values. Following this approach will mean onboarding a new developer is as simple as installing the database locally, creating a config file, committing the config file. This is a very simple and robust way to fix the local developer configuration problem 💥
Redirect Rules
Another common task on any project is adding redirect rules, the three most common ones being:
- Enforcing
httpsonly URLs - Enforcing a
www/non-wwwonly URLs - Enforcing a trailing/non-trailing slash policy
ASP.NET Core can host applications on both Windows and Linux. This means that the process of defining re-directs has changed from v8 to v9. As V8 used ASP.NET which used IIS, routing rules were written specifically to work with IIS. ASP.NET provides a few helpers to allow you to create these rules now, so they will work regardless of the environment that is hosting the application.
First, let us look at an HTTPS only policy. This policy can be created within Configure() inside of Start.cs, using this code:
It is also possible to apply a www policy to all your site URLs. You can do this using AddRedirectToWwwPermanent (you could use AddRedirectToWww but not recommended), like this:
Removing Trail Slash From A URL
Tidying Up Start.cs
Adding custom routing and redirect rules within start.cs will start to clutter the file up very quickly. Take this example:
In a large project, you will have a lot more than two rules. That is why adding redirects and rules like this will not scale. If you follow this approach, you will quickly clutter up your start.cs file. So what is a better alternative?
A better approach is to create a routing rule-specific UmbracoApplicationBuilderExtensions. Creating this file will reduce the clutter within start.cs. This approach will give your team a central area to add rules. Adding a custom UmbracoApplicationBuilderExtensions extension will mean that your code will be more declarative and easier to read. In order to create a custom UmbracoApplicationBuilderExtensions, create a new class like this:
As you can see on lines 10 and 15, you can add new routing rules by using EndpointRouteBuilder. Adding new routing rules has not changed much since ASP.NET. To create a rule you add a name, the trigger and then the mapping rules.
Writing To Log Files
When writing code, you should write logs to help make debugging easier. Writing log files has changed slightly in V9 compared to v8. The change is so minor that you will pick it up in seconds. Umbraco now relies on the ASP.NET Core way of logging. This uses Microsoft.Extensions.Logging. The code to start logging is shown below:
As Umbraco comes with dependency injection already configure, all you need to do is create a constructor with a parameter of type ILogger<T> where T is the name of the current class. Simply using the method found on like LogError(),LogInfo(), andLogWarning()` will give you a simple way to write to the log.
The logs will be written within log files found within the webroot. Within umbraco âž¡ logs. A more convenient way to look at the logs is found within the CMS. Log into the Umbraco backend, go to Settings âž¡ `log viewer.
Caching View Components
In ASP.NET Core the handy partial was replaced with View components. If you follow my tips in this video, you will set up your master layout using view components. To speed up development in v8 you used to be able to use CachePartial(). You can no longer use this within V9. Instead, you can use Tag Helpers. In its simplest form, you can wrap any call to a view component in cache tags to enable caching like this:
The tag helper has a few useful options you can enable to customise how the server will cache your view component, like expires-on, expires-sliding and vary-by-user. Within Umbraco this code would look like this:
This snippet is caching the call to render the header within my master layout. This tweak will improve my page response times very marginally, however, something is better than nothing 🤔
These tips may not be groundbreaking, however, getting these simple fundamentals correct will help ensure a high standard of coding within your application. Happy Coding 🤘
