.NET

Unit Testing dotnet new Templates

Unit Testing dotnet new Templates

, / 0 comments

As I talked about in my previous post some time ago about dotnet new project templates, it’s possible to enable feature selection, so that developers can toggle certain features of a project template on or off. This is not a feature that many templates in the wild use a lot. Quite often I’ve seen templates have no optional features or only a few. One reason is that it gets very complicated to test that toggling your optional features doesn’t break the generated project in some way by stopping it from building for example. This is why I decided to write a small unit test helper library for dotnet new project templates. It is unit test framework agnostic and can work with xUnit, NUnit, MSTest or any other unit test framework.

Example Usage

Below is an example showing how you can use it inside an xUnit test project.

The first thing it does in the constructor is install the dotnet new project templates in your solution. It needs to know the name of the solution file. It then walks the sub-directory tree below your solution file and installs all project templates for you.

If we then look at the first unit test, we first need a temporary directory, where we can create a project from our dotnet new project template. We will generate a project from the template in this directory and then delete the directory at the end of the test. We then run dotnet new with the name of a project template, the name we want to give to the generated project and any custom arguments that particular project template supports. Using xUnit, I’ve parameterised the arguments, so we can run multiple tests while tweaking the arguments for each test. Running DotnetNew returns a project which contains some metadata about the project that we’ve just created and we can also use it to further dotnet commands against.

Finally, we run dotnet restore and dotnet build against the project. So this test ensures that toggling the StatusEndpointOn option on our project template doesn’t stop the generated project from restoring NuGet packages or building successfully.

The second unit test method is where it get’s really cool. If the project template is an ASP.NET Core project, we can use dotnet run to start the project listening on some random free ports on the machine. The unit test framework then gives you two HttpClient’s (One for HTTP and one for HTTPS) with which to call your newly generated project. In summary, not only can you test that the generated projects build, you can test that the features in your generated project work as they should.

This API is pretty similar to the ASP.NET Core TestHost API that also gives you a HttpClient to test the API with. The difference is that this framework is actually running the app using the dotnet run command. I have experimented with using the TestHost API to run the generated project in memory, so it could be run a bit faster but the .NET Core API’s for dynamically loading DLL files needs some work which .NET Core 3.0 might solve.

Where To Get It?

You can download the Boxed.DotnetNewTest NuGet package or see the source code on GitHub.

The Dotnet Watch Tool Revisited

The Dotnet Watch Tool Revisited

, / 1 comment

I talked about using the dotnet watch tool with Visual Studio some time ago. Since then, a lot changed with the Visual Studio tooling and .NET Core 2.0 which broke the use of dotnet watch in Visual Studio, hence the reason for writing this post.

The ‘dotnet watch’ tool is a file watcher for dotnet that restarts the application when changes in the source code are detected. This is super useful when you just want to hack away at code and see the changes instantly when you refresh your browser. It increases productivity and reduces the magical inner-loop which reduces the time taken to write some code and then see it’s effects. I also like using this tool because it opens a console window which lets you see all of your logs flashing by.

Dotnet Watch Run Console

In both cases you have to be careful to start the application by clicking Debug -> Start Without Debugging or hitting the CTRL+F5 keyboard shortcut.

.NET Core 2.0 vs 2.1

Setting up the ‘dotnet watch’ tool is as easy as installing the Microsoft.DotNet.Watcher.Tools NuGet package if you are using .NET Core 2.0. If you are using .NET Core 2.1 or above, this tool comes pre-installed in the .NET Core SDK.

Now using powershell, you can navigate to your project folder and run the ‘dotnet watch run’ command and your set. But using the command line is a bit lame if you are using Visual Studio, we can do one better.

launchSettings.json

The launchSettings.json file is used by Visual Studio to launch your application and controls what happens when you hit F5. It turns out you can add additional launch settings here to launch the application using the ‘dotnet watch’ tool. You can do so by adding a new launch configuration as I’ve done at the bottom of this file:

Notice that I renamed the second launch profile (which already exists in the default template) to ‘dotnet run’ because that’s actually the command it’s running and makes more sense.

The ‘dotnet watch’ launch profile is running the ‘dotnet watch run’ command as an executable and using the current working directory of the project. Now we can see the new launch profile in the Visual Studio toolbar like so:

Dotnet Watch in the Visual Studio Toolbar

ASP.NET Core Boilerplate Templates

I’ve updated the ASP.NET Core Boilerplate family of project templates with this feature built in. Happy coding!

ASP.NET Core Caching in Practice

ASP.NET Core Caching in Practice

, / 11 comments

Cache-Control HTTP Header

The Cache-Control HTTP header can be used to set how long your resource can be cached for. However, the problem with this HTTP header is that you need to be able to predict the future and know before hand when the cache will become invalid. For some use cases, like writing an API where someone could change the resource at any time that’s just not feasible.

I recommend you read the response caching middleware documentation, it’s not necessary as I do a quick overview next but the knowledge below builds upon it. The simple way to set the cache control header is directly on the action method like so:

Adding the ResponseCache attribute just adds the Cache-Control HTTP header but does not actually cache the response on the server. To do that you also need to add the response caching middleware like so:

Instead of hardcoding all of your caching settings in the ResponseCache attribute, it’s possible to store them in the appsettings.json configuration file. To do so, you need to use a feature called cache profiles which look like this:

Now all your caching can be configured from a single configuration file.

Cache-Control Immutable Directive

Cache-Control also has a new draft directive called ‘immutable’. When you add this to the HTTP header value, you are basically telling the client that this resource never changes even if it has expired. You might be asking, why do we need this? Well, it turns out that when you refresh a page in a browser, it goes off to the server and checks to see if the resource has expired or not.

It turns out that you get a massive reduction in requests to your server by implementing this directive. Read more about it in these links:

This directive has not yet been implemented in ASP.NET Core but I’ve raised an issue on GitHub here and there is also another issue here to add the immutable directive to the static files middleware. If you really wanted to, it’s really easy to add this directive today, as you just need to append the word ‘immutable’ onto the end of your Cache-Control HTTP header.

A word of warning! You need to make sure that your resource really never changes. You can do this in Razor by usign the asp-append-version attribute on your script tags:

This will append a query string to the link to site.js which will contain a hash of the contents of the file. Each time the file changes, the hash is changed and thus you can safely mark the resource as immutable.

E-Tags

E-tags are typically generated in three ways (Read the link to understand what they are):

  1. Hashing the HTTP response body – You’d want to use a very fast and collision resistant hash function like MD5 (MD5 is broken security wise and you should never use it but it’s ok to use it for caching).
    Unfortunately, this method is slow because you have to load the entire response body into memory (which is not the default in ASP.NET Core which streams it straight to the client for better performance) to hash it.
    If you’re still interested in implementing this E-Tags using this method Mads Kristensen wrote a nice blog post showing how it can be done.
  2. Last modification timestamp – The E-Tag can literally be the time the object was last modified which you can store in your database (I usually store created and modified timestamps for anything I store in a database anyway). This solves the performance problem above but now what is the difference between doing this and using the Last Modified HTTP header?
  3. Revision Number – This could be some kind of integer stored in the database which gets incremented each time the data is modified. I don’t see any advantage of doing this over using the last modification timestamp above, unless you have a naturally occuring revision number in your data that you could use.

One additional thing you need to be careful of is the Accept, Accept-Encoding and Accept-Language HTTP headers. Any time you send a different response based on these HTTP headers, your E-Tag needs to be different e.g. a JSON non-gzipped response in Mandarin needs to have a different E-Tag to an XML gzipped response in Urdu.

For option one, this can be achieved by calculating the hash after the response body has gone through GZIP compression. For the second and third options, you would need to append the value of the Accept HTTP headers to the last modified date or revision number and then hash all of that.

Last-Modified & If-Modified-Since

I’m assuming you already know about the Last-Modified and If-Modified-Since HTTP headers. If not, go ahead and read the links. Below is an example controller and action method that returns a list of cats.

All of our cats have a ModifiedTimestamp, so we know when they were last changed. There are four scenarios that this action method handles:

  1. Our repository does not contain any cats, so just always return an empty list.
  2. No Last-Modified HTTP header exists in the request, so we just return all cats.
  3. Last-Modified HTTP header exists and cats have been modified since that date, so return all cats.
  4. Last-Modified HTTP header exists but no cats have been modified since that date, so return a 304 Not Modified response.

In all cases, except when we have no cats at all, we set the Last-Modified date to the latest date than any cat has been modified.

Conclusions

Which caching HTTP headers you pick, depends on your data but at a minimum, I would add E-Tags or Last-Modified. Add Cache-Control where possible, usually for static assets.

Structured Data using Schema.NET

Structured Data using Schema.NET

, / 18 comments

What is Schema.org?

Schema.org defines a set of standard classes and their properties for objects and services in the real world. There are nearly 700 classes at the time of writing defined by schema.org. This machine readable format is a common standard used across the web for describing things.

Where is Schema.org Used?

Websites

Websites can define Structured Data in the head section of their html to enable search engines to show richer information in their search results. Here is an example of how Google can display extended metadata about your site in it’s search results.

Google Logo Structured Data Example

Using structured data in html requires the use of a script tag with a MIME type of application/ld+json like so:

Windows UWP Sharing

Windows UWP apps let you share data using schema.org classes. Here is an example showing how to share metadata about a book.

Enter Schema.NET

Schema.NET is Schema.org objects turned into strongly typed C# POCO classes for use in .NET. All classes can be serialized into JSON/JSON-LD. Here is a simple Schema.NET example that defines the name and URL of a website:

The code above outputs the following JSON-LD:

There are dozens more examples based on Google’s Structured Data documentation with links to the relevant page in the unit tests of the Schema.NET project.

Classes & Properties

schema.org defines classes and properties, where each property can have a single value or an array of multiple values. Additionally, properties can have multiple types e.g. an ‘Address’ property could have a type of ‘string’ or a type of ‘PostalAddress’ which has it’s own properties such as ‘StreetAddress’ or ‘PostalCode’ which breaks up an address into it’s constituent parts.

To facilitate this Schema.NET uses some clever C# generics and implicit type conversions so that setting a single or multiple values is possible and that setting a ‘string’ or ‘PostalAddress’ is also possible:

This magic is all carried out using the ‘Value<T>’, ‘Value<T1, T2>’, ‘Value<T1, T2, T3>’ etc. types. These types are all structs for best performance too.

Where to Get It?

Download the Schema.NET NuGet package or take a look at the code on GitHub. At some point I’ll find the time to write a quick ASP.NET Core tag helper that wraps Schema.NET.

ASP.NET Core Lazy Command Pattern

ASP.NET Core Lazy Command Pattern

, / 16 comments

TLDR: Move your ASP.NET Core MVC action method logic into lazily loaded commands using the command pattern.

When writing your Controllers in ASP.NET Core, you can end up with a very long class if you’re not careful. You may have written several action methods with a few lines of code in each, you may be injecting a few services into your controller and you may have commented your action methods to support Swagger. The point is it’s very easy to do, here is an example:

The Command Pattern

This is where the command pattern can come in handy. The command pattern moves logic from each action method and injected dependencies into their own class like so:

All the logic and dependencies in the controllers gets moved to the command which now has a single responsibility. The controller now has a different set of dependencies, it now lazily injects one command per action method.

You may have noticed the IAsyncCommand interface. I keep four of these handy to inherit from. They all outline an ExecuteAsync method to execute the command and return an IActionResult but they have a differing number of parameters. I personally feel if you are needing more than three parameters you should be using a class to represent your parameters, so I’ve put the limit on three parameters.

Why so Lazy?

Why do we use Lazy<T>? Well the answer is that if we have multiple action methods on our controller, we don’t want to instantiate the dependencies for every action method if we are only planning on using one action method. Registering our Lazy commands requires a bit of extra work in out Startup.cs. We can register lazy dependencies like so:

HttpContext and ActionContext

Now you might be thinking, how do I access the HttpContext or ActionContext if I want to set a HTTP header for example? Well, you can use the IHttpContextAccessor or IActionContextAccessor interfaces for this purpose. You can register them in your Startup class like so:

Notice that they can be registered as singletons. You can then use them to get hold of the HttpContext or ActionContext objects for the current HTTP request. Here is a really simple example.

Unit Testing

Another upside to the command pattern is that testing each command becomes super simple. You don’t need to setup a controller with lots of dependencies that you don’t care about. You only need to write test code for that single feature.

Conclusions

For a full working example, take a look at the ASP.NET MVC Boilerplate API project template which makes full use of the Lazy Command Pattern.

dotnet new Feature Selection

dotnet new Feature Selection

, / 2 comments

In my last post I showed how to get started with using dotnet new to build project templates. In this post, I’m going to build on that knowledge and show how to add feature selection to your project template so developers can choose to add or remove bits of your template. If you check out my Boilerplate API project template, you’ll see that I have 17 features for you to set. If you run the help command against my template you’ll see a description of each and instructions on how you can set them (I’ve cleaned up the CLI output, the current help commands output is pretty awful but this is being addressed in the next version of dotnet new).

As you can see from the output, there are a few different types of feature you can create. You can also choose to make a feature required or optional. An optional feature, if not specified by the user will fall-back to a default value. Here are the different types available:

  • bool – This feature can be turned on or off and has a default of true or false.
  • string – This can be used to do a string replacement in your template. It has a default value which you can set to any arbitrary value.
  • choice – This is a feature with two or more named choices. Each choice can have it’s own description. The default value must be one of the choices.
  • computed – These are features flags that can be computed based on other symbols.

Bool Symbols

You can create a boolean feature by adding symbols section to your template.json file. If you look at the example below, I’ve specified an optional bool symbol, with a default value of true.

In your code, you can then use the symbol name, in this case ‘Swagger’ as a pre-processor directive in C# code:

This is really cool because you can still run the application as a template author and the project will still work. If you define a ‘Swagger’ constant in your project properties, your feature will turn on or off too. This makes debugging your project template very easy as a template author.
 
If you want to use the symbol in files other than C# where pre-processor directives do not exist, you can use the comment syntax specific to that file extension, so in a JavaScript file would use the ‘//’ syntax:

Most file extensions that have their own comment syntax have been catered for. For text files where there is no comment syntax or for any file extension that the templating engine doesn’t know about you can use the ‘#’ character:

You can look at this code in the templating engine for a full list of supported file extensions and comment types.

String Symbols

String symbols can be used to do simple file replace operations.

The above symbol looks for a ‘PROJECT-TITLE’ string and replaces it with whatever the user specifies or with the default value ‘Default Project Title’ if the user doesn’t set anything.

Choice Symbols

A choice symbol is useful when you have more than two options and can’t use bool.

In the example above, you have the choice of selecting a target framework, with a value of .NET Core, .NET Framework or Both. Each choice has it’s own description and the overall symbol also has it’s description.

Computed Symbols

In the above example, you can’t use the value ‘.NET Core’ as a C# pre-processor variable because it contains a dot and a space. This is where a computed symbol comes in handy.

Here I have set up two computed symbols which determines whether ‘.NET Core’ or ‘.NET Framework’ was selected individually in the previous choice symbol. I have named these symbols without a dot or space i.e. ‘NETCore’ and ‘NETFramework’ so I can use these as C# pre-processor symbols, the same way I showed above.

Conditionally Deleting Files or Folders

You can also use symbols to delete certain files or folders. In this example, I’ve extended my bool symbol example to additionally remove two files and a folder if the feature is deselected by the user.

You do this by adding source modifiers. I’ve added one here with a condition and three file and folder exclusions. The exclusions use a globbing pattern.

What’s Next?

There are several other useful features of the templating engine which I’ll cover in a follow up post as this is starting to get quite long. Feel free to take a look at the source code for my API template to see a full example.

Cleaning Up CSPROJ

Cleaning Up CSPROJ

, / 1 comment

TLDR: I show how to make csproj XML concise and pretty for hand editing.

I used project.json since Beta 7 and got used to hand editing it, I’ve continues that practice with csproj and I think you should too. Recent version of Visual Studio have made a lot of performance improvements but it’s still a lot slower than hand editing a text file.

The NuGet package screen in Visual Studio is achingly slow. Bulk editing takes seconds. I can update NuGet package references, package properties etc. all in one go, rather than visiting multiple disparate UI’s in Visual Studio. Finally, I create new projects by copying and pasting an existing csproj and tweaking it. Much faster than Visual Studio’s New Project dialogue.

Install Project File Tools

The Project File Tools Visual Studio extension gives you intellisense for NuGet packages in the new csproj projects. Unfortunately, due to MSBuild being around for so long and being so complex, intellisense for the rest of the project XML consists of a massive list of possible properties so it becomes less useful than it was in project.json.

dotnet migrate – Wow that’s ugly!

After migrating my project.json projects to csproj using Visual Studio 2017 (You could also use the dotnet migrate command), I found that that the XML generated was pretty ugly and contained superfluous elements you just didn’t need. Here is an example csproj library project straight after migration:

Understanding new csproj Projects

The top of the project contains a new SDK property. This imports some MSBuild targets and props files in your dotnet installation folder shown below:

dotnet SDK's

If you root around in those files, you can find defaults for all kinds of settings. Here are some of the nuggets I discovered about the web projects:

  • The NETStandard.Library version 1.6.1 NuGet package is referenced for you by default.
  • The wwwroot folder is excluded from compilation but included in the published output.
  • web.config, .cshtml and .json files are published by default.
  • Server garbage collection is turned on by default using the ServerGarbageCollection setting.
  • PreserveCompilationContext is set to true by default.
  • node_modules, jspm_packages and bower_components are excluded by default.

AssemblyInfo.cs is Partially Dead

You don’t need AssemblyInfo.cs anymore by default as the csproj Package settings also set many of the assembly attributes. In fact, you didn’t really need it with project.json either but the default templates mostly included it for some reason. However, I still found I needed to resurrect it in some cases to use the InternalsVisibleTo attribute. InternalsVisibleTo allows my unit test projects to access internal members in my library project. After a dotnet migrate, you may see the following elements which stop certain assembly attributes from being generated. You can safely delete these.

Remove System.* References

You no longer need to explicitly reference System.* references in your csproj. David Fowler recommends that you always reference the NETStandard.Library meta NuGet package gives you most System.* references. You get NETStandard.Library by default if you use the SDK attribute at the top of the csproj:

This meant that I could remove the entire code block below except System.ServiceModel because that reference is not given to you by the NETStandard.Library NuGet package.

Turn Elements into Attributes

For some reason dotnet migrate produces overly verbose XML in some cases by outputting XML elements instead of attributes. I have a NuGet reference to StyleCop.Analyzers which is a build time dependency and I don’t want it to be output to my bin directory. You do this by setting the PrivateAssets property but you can turn this:

Into this:

Label your Sections

You can label your PropertyGroup and ItemGroup elements using the Label attribute:

So the question becomes, how should we label them? Well, the convention I use is to use the same label names as the ones in Visual Studio’s project properties screen:

Project Properties Tabs

The End Result

This is what my csproj looks like at the end of all that. I’ve removed all the extra fluff you don’t need and labelled the properties in a way that makes navigating the file with yoour eye that much quicker.

 

Custom Project Templates Using dotnet new

Custom Project Templates Using dotnet new

, / 13 comments

Current dotnet new

If you run dotnet new today, you can create a simple console app. The command has very few options, including selecting the language you want to use (C#, VB or F#). However, this is all about to change. Sayed I. Hashimi and Mike Lorbetske who work at Microsoft in the .NET tooling team have been kind enough to show me what they’ve been working on with the intention of getting some feedback.

old dotnet new

dotnet new3

Microsoft is working on a new version of the dotnet new command with support for installing custom project templates from NuGet packages, zip files or folders. If you head over to the dotnet/templating GitHub repository you can follow the very simple instructions and try out a fairly complete version of this command which is temporarily called ‘dotnet new3’. The full ‘dotnet new’ experience is due to be released in conjunction with Visual Studio 2017.

dotnet new3

If you take a look at the screenshot above, you’ll notice that there are a lot more options available. You can list all installed project templates and install new ones too.

Creating New Templates

Creating a new project template involves taking a folder containing your project (Mine is called Api-CSharp) and adding a .template.config folder to it containing two files.

Custom project template example folder structure

Template Metadata

The template.json file is where you specify metadata about your project template. This metadata is displayed when someone lists their installed project templates. A really basic one looks like this:

The templating repositories Wiki page talks about what all of the properties mean in a lot more detail but I’ve added some basic comments for your understanding.

Installing Templates

Installing the above template from a folder is as easy as using the install command. You can also install templates from zip files and NuGet packages the same way.

Template NuGet Packages

So how do you create a NuGet package containing a project template thats compatible with dotnet new? I’m assuming you are familiar with creating NuGet packages, if not take a look at the NuGet documentation. You can create NuGet packages of your project templates by creating a Templates.nuspec file like the one below and placing all of your templates in a content folder beside it. The content folder is a special folder which NuGet understands to contain static files. If you look at the nuspec file below, you’ll notice the packageType element. This is a new way to tell NuGet that this NuGet package contains project templates.

There is More!

What I’ve not told you is that it’s possible to add features to your project template that developers can turn on or off based on command line switches a bit like Yeoman does for Node based NPM packages. As many of you will know I already do this in my ASP.NET MVC Boilerplate project template but I came up with my own custom method. dotnet new makes this all a lot easier and I’ll cover how to do this in a later blog post.

Why This is Better

Traditionally, to create project templates, you could use Visual Studio to create zip files containing your project template or if you were brave you could create Visual Studio extensions (VSIX) to enable installing them directly into Visual Studio and share them on the Visual Studio Marketplace.

This new method makes creating project templates about as easy as it’s ever going to get and allows really easy sharing, versioning and personalization of project templates. At some point I envisage a website (Possible the Visual Studio Marketplace) where you could go and install these NuGet based project templates.

ASP.NET Core Boilerplate API

I’ve been working on a brand new project template for building API’s using dotnet new with a lot of help from the guys at Microsoft. My project templates are quite complex so it’s a good test of the system. The API comes jam packed full of security, performance and best practice features and also implements Swagger right out of the box. It’s still in alpha quality but you can try installing it with dotnet new3 from MyGet and soon NuGet when I get a chance to polish it up a little more.

Conclusions

Overall I’m really impressed with where the new project templating system is headed. It’s very easy to do something simple but also very powerful should you need to do something complicated. There is a few blog posts worth of material here, so expect a few more posts in the coming weeks.

Reactive Extensions (Rx) – Part 8 – Timeouts

Reactive Extensions (Rx) – Part 8 – Timeouts

, , / 1 comment

In part six of this series of blog posts I talked about using Reactive Extensions for adding timeout logic to asynchronous tasks. Something like this:

Last week I was working on a project and wanted to add a Timeout to my task but since it was an ASP.NET MVC project, I had no references to Reactive Extensions. After some thought I discovered another possible method of performing a timeout which may help in certain circumstances.

I’m using an overload on CancellationTokenSource which takes a timeout value. Then passing the CancellationToken to DownloadTheInternet. This method should be periodically checking the CancellationToken to see if it has been cancelled and if so, throw an OperationCanceledException. In this example you’d probably use HttpClient which handles this for you if you give it the CancellationToken.

The main reason why this method is better is that the task is actually being cancelled and stopped from doing any more work. In my above reactive extensions example, the task continues doing work but it’s result is just ignored.

SEO Friendly URL’s for ASP.NET Core

SEO Friendly URL’s for ASP.NET Core

, / 9 comments

For some reason there are not a lot of Search Engine Optimization (SEO) blog posts or projects out there. Taking a few simple steps can make your site rank higher in Google or Bing search results so it’s well worth doing. Here are a few other of my SEO related blog posts:

What is an SEO Friendly URL?

This Mozilla blog post called ‘15 best practices for structuring URL’s’ is the best article on the subject of SEO friendly URL’s I found and it’s well worth a read.

Essentially you want a simple short URL that tells the user what they are clicking on at a glance. It should also contain keywords pertaining to what is on the page for better Search Engine Optimization (SEO). In short, a page will appear higher up in search results if the term a user searches for appears in the URL. Your URL should look like this:

SEO Friendly URL Example

The URL contains an ID for a product and ends with a friendly title. The title contains alphanumeric characters with dashes instead of spaces. Note that the ID of the product is still included in the URL, to avoid having to deal with two friendly titles with the same name.

If you elect to omit the ID, then you have to do a lot of footwork to make things work. Firstly, you have to use the title as a kind of primary key to get the product data from your database and secondly, you also have to figure out what to do when there are two pages with the same title. Each time you want to create a new title, you have to scan your data store to see if the title already exists and if it does either error and force the creation of a different title or add make it unique by adding a number on the end. This is a lot of work but does produce a nicer URL, the choice is yours.

How to Build One

Take a look at the controller action below. It is a very simple example of how to use SEO friendly URL’s. In our example we have a product class which has a ID and title properties, where the title is just the name of the product.

All the work is done by the FriendlyUrlHelper which turns the product title which may contain spaces, numbers or other special characters (which would not be allowed in a URL without escaping them) into a lower-kebab-case title.

This generated friendly title is compared with the one that is passed in and if it is different (Someone may have omitted the friendly title or mis-spelled it) we perform a permanent redirect to the product with the same ID but now with the friendly title. This is important for SEO purposes, we want search engines to only find one URL for each product. Finally, if the friendly title matches the one passed in we return the product view.

The FriendlyUrlHelper

The FriendlyUrlHelper was inspired by a famous StackOverflow question ‘How does Stack Overflow generate its SEO-friendly URLs?‘. The full source code for it is shown below.

The difference between my version and the one in the StackOverflow answer is that mine optionally handles non-ASCII characters using the boolean remapToAscii parameter. This parameter remaps special UTF8 characters like ‘è’ to their ASCII equivalent ‘e’. If there is no equivelant, then those characters are dropped. All modern browsers except Internet Explorer and Edge display the ‘è’ correctly. Older browsers like Internet Explorer percent encode these international characters so they are displayed as’%C3%A8′. What you set this to depends on whether your target users are English speakers and if you care about supporting IE and Edge. I must say that I was hoping Edge would have added support so that remapToAscii could be turned off by default but I’m sorely dissapointed.

Using the third parameter you can specify a maximum length for the title with any additional characters being dropped. Finally, the last thing to say about this method is that it has been tuned for speed.

Where Can I Get It?

This is a great little snippet of code to make your URL’s a human readable, while giving your site an SEO boost. It doesn’t take much effort to use either. This helper class is available in the Boilerplate.AspNetCore NuGet package or you can look at the source code in the ASP.NET MVC Boilerplate Framework GitHub page.

Load More