Imagesharp: Add .NET 5 as an explicit target framework.

[JimBobSquarePants]

We need to add ARM intrinsics in order to maintain performance on platforms such as Windows ARM 64.

Adding these intrinsics requires .NET 5.

@tannergooding has already indicated he would be interested in helping out with implementations, I'm keen to learn also.

Adding the target should be trivial enough. Any individual optimization/feature tasks can be raised as and when required.

[antonfirsov]

There are several questions that need to be answered before a commiting to this.

1. How many ARM users do we have? What are their use cases? Are the costs worth the benefits? Aren't there other (more important) topics where we can benefit them? (Eg. guaranteeing AOT-friendliness)

2. How can we provide reliable CI coverage for ARM 64?

[JimBobSquarePants]

There's no way to answer 1. We have no metrics. For 2. We'd need a Docker image for now as there are no native images available.

[brianpopow]

There's no way to answer 1. We have no metrics. For 2. We'd need a Docker image for now as there are no native images available.

I tried to run the ImageSharp tests with docker / ARM Image in the past without success so far. It seems docker for windows uses QEMU to emulate an ARM cpu when the host CPU is not ARM. This fails with some serious fatal errors when executing the tests.
Something like this:

qemu: uncaught target signal 6 (Aborted) - core dumped

Last time i checked is already a year ago, but if nothing essentially changed with docker for windows and QEMU, i dont have high hopes that it will work.
There are new docker ARM images from .net now with the new .Net 5 release, maybe i should give it another try.

edit:
Surprisingly to me, i was actually able to run the tests with docker now with the following image: mcr.microsoft.com/dotnet/sdk:3.1.404-buster-arm64v8

But there are two important downsides running the tests with docker / ARM:

• .Net Core does not officially support QEMU (which is my main concern)
• Its very slow: doing the dotnet restore took roughly 10 minutes and running the tests also about 10 minutes.

[kleisauke]

2. How can we provide reliable CI coverage for ARM 64?

Not many CI providers supports ARM64, unfortunately. At the time of writing:

• Travis supports Linux ARM64 in an early beta stage, only for OSS-projects. Windows ARM64 is unsupported.
• GitHub actions only supports self-hosted Linux ARM64 jobs. The Windows ARM64 runner is work-in-progress.
• Azure Pipelines only supports self-hosted Linux ARM64 jobs. The Windows ARM64 agent is unsupported in Azure DevOps.
• AppVeyor does not support ARM64.

There are new docker ARM images from .net now with the new .Net 5 release, maybe i should give it another try.

fwiw, I had success with running the mcr.microsoft.com/dotnet/sdk:5.0-buster-slim-arm64v8 Docker image on a Linux ARM64 based Travis runner. See for example this configuration (relevant job log can be viewed here).

[JimBobSquarePants]

Thanks! @kleisauke