Use ng serve with Angular 8 and Internet Explorer

Angular 8 introduced the new ECMAScript standard ES2015. ES2015 is more efficient. Older browsers like IE 11 does support only the previously used ES5. To still have support for IE 9-11 Angular has new feature called Differential Loading. In short it is serving the Angular App in two versions: a ES5 version and ES2015 version. So each browser can decide which version to use.

Unfortunately if your using the Angular Develpment Server ng serve, it will use only ES2015. The reason is, that it would be too slow to compile it always twice for ES2015 and ES5.

There’s a trick how to run ng serve with ES5.

In the file browserslist remove the “not” before “IE 9-11”.

> 0.5%
last 2 versions
Firefox ESR
not dead
IE 9-11

Beside your tsconfig.json add a file tsconfig-es5.json with content:

{
    "extends": "./tsconfig.json",
    "compilerOptions": {
        "target": "es5"
    }
}

Add a new configuration “es5” in the “configurations” and “serve” sections of your angular.json:

{
  ...
  "projects": {
    "my-app": {
      ...
      "configurations": {
        ...
        "es5": {
          "tsConfig": "./tsconfig-es5.json"
        }
      }
    },
    "serve": {
      ...
      "configurations": {
        "production": {
          "browserTarget": "my-app:build:production"
        },
        "es5": {
          "browserTarget": "my-app:build:es5"
        }
      }
    }
    ...
  }
}

Optionally you can add a script to package.json:

"scripts": {
  "start": "ng serve",
  "ie": "ng serve -c es5",
}

Now you can run your Angular App with IE support using:

npm run ie

async/await: Why don’t use Task.Wait()?

In short explained why you should never use Task.Wait() to wait for an asynchronous task to complete from a synchronous context.

The Wait() method always returns an AggregateException if an error occurs within the task execution.

It would be hard to handle the real exception which is wrapped within the AggregateException.

Use GetAwaiter().GetResult() instead. It will return the real exception.

Generate a self-signed certificate for IIS with a custom common name

Using the IIS Manager you can generate self-signed certificates for HTTPS bindings. The certificates generated by the IIS Manager have the limitation that the common name (CN) of the certificate is always the computer name.

If you wish to set an own common name for the certificate, you can use following command in PowerShell (open as administrator) to generate a new self-signed certificate.

New-SelfSignedCertificate -DnsName "my.customdomain.com" -FriendlyName "MyServiceName" -NotAfter (Get-Date).AddYears(10)

Challenge authentication using a custom middleware.

Sometimes you write an ASP.NET Core application without using MVC. For example an microservice or an application serving static files.

Anyhow you might want to secure your application using authentication. I was facing the problem, how I could challenge authentication when I’m not using MVC.

The solution is writing a custom middleware that challenges authentication.