This is a mono repository for several NuGet packages based on the Microsoft.Extensions.Diagnostics.HealthChecks package. The main goal of this repository is to provide a set of health checks for different services and frameworks, which are fully configurable either via code or configuration.
What is the difference between this repository and the AspNetCore.Diagnostics.HealthChecks repository?
The main difference is that we try to focus on providing packages that are fully configurable via code or configuration. This means that you can configure the health checks in your Program.cs file, or in your appsettings.json file, or in any other configuration provider. In some cases, we provide the same healthcheck for a service with an alternative implementation. For example, we provide a healthcheck for MySql that is based on MySql.Data and one that is based on MySqlConnector. This allows you to choose the implementation that best suits your needs or fits your existing dependencies.
In addition, we try to support the latest LTS and STS versions of .NET (.NET Support Policy) as well as the latest preview version of .NET for at least 3 years, but we can't guarantee this. This depends on the support of related NuGet packages and the .NET platform itself. See the Supported .NET Version section for more details.
The following table lists all currently available NuGet packages. For more details about the packages, please visit the corresponding NuGet page.
The package names are based on the following naming schema - NetEvolve.HealthChecks.<GroupName?>.<ServiceName>
The GroupName is optional and is used to group related services. For example, all azure platform services are grouped under Azure. The ServiceName is the name of the service for which the health check is provided. For example, SqlServer or MySql.
The following table lists all planned and used groups. We will add more groups maybe in the future, if the demand is there.
- Apache
- AWS
- Azure
- GCP
We try to support the LTS and STS versions of .NET (.NET Support Policy), as well as the latest preview version of .NET. We will try to support each framework version for at least 3 years, but we can't guarantee it. This depends on the support of related NuGet packages and the .NET platform itself.
| .NET Version | Supported |
|---|---|
| .NET Standard | ❌ No |
| .NET 5.0 or earlier versions | ❌ No |
| .NET 6.0 | ✅ Yes, until Dec. 2024 |
| .NET 7.0 | ✅ Yes, until Jun. 2024 at the earliest |
| .NET 8.0 | ✅ Yes |
| .NET 9.0 | ❌ No, until Apr. 2024 at the earliest |
Why did we choose this approach? Because we want to be able to take advantage of the latest language features of the .NET platform and the performance gains that come with them. We know that not all of our NuGet packages will gain performance from this, but this is our general strategy and nobody knows what the future will bring.
To get more information about the end-of-life (EOL) date for the relevant components, please visit the website of the creators of the components or try the website endoflife.date.
With the .NET Standard Microsoft created a specification for APIs that are intended to be available on all .NET implementations. This was a great idea, but it also has some drawbacks. The main drawback is that the .NET Standard is a specification and not an implementation. This means that the real work is done by .NET implementations, such as .NET 5.0 and later versions. Which is why we decided us against the .NET Standard and for the concrete .NET implementations.
See The future of .NET Standard for more details.