* Use options for registering health checks
This change pivots to use options for registering health checks. We get
a few pretty nice things out of this, and it unblocks some of our
requirements.
Now all registration methods support the application developer
configuring the name, failure-status, and tags for each health check.
This is a requirment, that we weren't really satisfying - which is what
led to this redesign. In support of this health checks now return pass/fail,
and the service is responsible for assigning the status.
----
Health check authors that need configuration data (connection string as
an example) now have three ways to do this depending on their
requirements.
1. Create an instance and register that (easiest)
2. Use Type Activation and pass parameters (middle)
3. Use named options (richest)
We expect most health checks to need/want some kind of configuration -
which 1) works pretty well to solve. However many other health checks
will need DI + configuration. It was also a gap that we didn't have a
good way to use named options, when it's such a good fit for our
scenarios.
Added new registration methods for type activation that allow you to
pass parameters for 2).
Added a context type that allows the running health check access to its
registration for 3).
----
Redesigned and renamed how status gets reported. Health checks return
pass/fail result, but the overall HealthReport includes entries of a
different type. This seems fine because there isn't really a way to
consume a HealthCheckResult directly - the service is the only consumer.
----
Added support for tags. This was easy to add now that we have a separate
registration type, and it's quite handy for building filters (see
sample).
* HARDER BETTER STRONGER FASTER
This allows users to use `ProducesAttribute` to specify the content-type
for action results such as FileStreamResult where the result determines the content type
and the specified value is informational.
Fixes https://github.com/aspnet/Mvc/issues/5701
Loading multiple versions of a task assembly result results in MSBuild on .NET Core to fail.
Addressing this by moving the tasks in to the Sdk and renaming it. This should avoid
immediate issues for a 2.1 and 2.2 project co-existing and future proofs 2.2 and later.
Fixes https://github.com/aspnet/Razor/issues/2553
- 30a5eda508 / origin/prkrishn/form-file-value-provider
Was:
Design: Use a value provider to allow nested form files
Fixes https://github.com/aspnet/Mvc/issues/7562
- #7562 part 2
- add `OriginalModelName` to `ModelBindingContext`
nit: take VS suggestions, mostly to inline collection initialization in `FormFileModelBinderTest`
Pavel Krymets
BrennanConroy
Ryan Nowak
Pranav K
ASP.NET CI
Mike Harder
Justin Kotalik
Mikael Mengistu
Brice Lambson
Ryan Brandenburg
Stephen Halter
Doug Bunting
Matt Mitchell
tiago-soczek
Chris Ross (ASP.NET)
David Fowler
John Luo