- thanx to @NTaylorMullen for initial conversion
- e.g. AssemblyInfo.cs files were already minimized or removed :)
- allow `>=` RC3 CLI's to build and run MVC
- work around several dotnet migration issues; see #5482
- disable full .NET Framework runs of functional tests; see #5873
- remove `Microsoft.DotNet.InternalAbstractions` and `System.Xml.XmlDocument` dependencies
- remove project.json (!!), *.xproj, .notest, and web.config files
Redo earlier changes:
- apply test migration to .NET 4.5.2 in *.csproj world
- see 63507c8 for previous, project.json work
- apply dependency version downgrade from 0097e40 in *.csproj world
Make other test-related changes:
- make Microsoft.AspNetCore.Mvc.TestDiagnosticListener a regular class library
- add support for `/p:GenerateBaselines=true` for functional and Razor.Host tests
- separate `GetCSharpTypeName_ReturnsCorrectTypeNames_ForOutParameter()` test
- work around inability to deserialize a odd `ref` type
- xUnit and vstest now serialize / deserialze test data more often
- skip poor test mentioned in #5768
- work around Microsoft/vstest#392
- rename tests to avoid duplicates
- work around Microsoft/vstest#419
- set up created `AppDomain`s with current `ApplicationBase`
- aspnet/Testing#248
- xUnit no longer supports .NET 4.5.1
- update AppVeyor config so this framework version is available
- build tests for desktop .NET only on Windows
Fixes compilation error "The type 'XmlNode' exists in both 'System.Xml.ReaderWriter, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' and 'System.Xml.XmlDocument, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'"
This test uses the new features in the service provider to verify that we
don't reference any scoped services from singletons.
Note that this can't really cover the cases where we have optional
services or where we replace default services (like DI for controllers).
You'll just have to be careful.
'ValidationExcludeFilter' -> 'SuppressChildValidationMetadataProvider'
Also moved to .ModelBinding for improved discoverability. There aren't
many reasons user code would have a using for .Validation.
- #4339: remove non-recommended JSON formatter constructors
- affects `JsonInputFormatter`, `JsonOutputFormatter`, `JsonPatchInputFormatter`
- `JsonOutputFormatter` cleanup also impacts `JsonHelper`
- rename and make `SerializerSettingsProvider` class public; use it as appropriate
- #4409: make `SerializerSetings` properties get-only and `protected`
- affects `JsonInputFormatter`, `JsonOutputFormatter`
Recommended patterns:
- change `JsonSerializerSettings` values in `MvcJsonOptions` for almost all customizations
- find `JsonOutputFormatter` in `MvcOptions.OutputFormatters` when limiting per-result formatters
- start with `JsonSerializerSettingsProvider.CreateSerializerSettings()` when customizing a per-result formatter
* Added TagHelperFeature and TagHelperFeatureProvider to perform tag helper discovery.
* Changed tag helper discovery to use application parts when using tag helpers as services.
* Added FeatureTagHelperTypeResolver to resolve tag helper type definitions from the list of application parts.
* Added AddTagHelpersAsServices extension method on IMvcBuilder and IMvcCoreBuilder that
performs tag helper discovery through the ApplicationPartManager and registers those tag helpers as
services in the service collection. Assemblies should be added to the ApplicationPartManager
in order to discover tag helpers in them in them. The @addTagHelper directive is still required on
Razor pages to indicate what tag helpers to use.
* Added ViewComponentFeture and ViewComponentFeatureProvider to perform view component discovery.
* Changed view component discovery to use application parts.
* Changed ViewComponentDescriptorProvider to make use of Application parts.
* Added AddViewComponentsAsServices method on IMvcBuilder that performs view component
discovery through the ApplicationPartManager and registers those view components as
services in the service collection. Assemblies should be added to the ApplicationPartManager
in order to discover view components in them in them.
This commit introduces application parts as a concept on MVC.
An application part is an abstraction that allows you to expose some
feature or corncern in a way that is decoupled from their underlying source.
Examples of this include types in an assembly, emdeded resources, files on
disk etc.
Application parts are configured during startup by adding or removing them from
the application part manager available as part of IMvcBuilder and IMvcCoreBuilder.
The application part manager provides the ability to populate features from the
list of available application parts by using a list of application feature providers.
Application feature providers are responsible for populating a given feature given a
list of application parts.
Examples of application providers can be a ControllerFeatureProvider
that goes through the list of application parts, sees which one of those parts exposes types,
determines which of those types are controller types, and adds them to a ControllerFeature
that holds a list of all the types that will be considered controllers in the application.
This change separates model binding into IModelBinderProvider (decides
which binder to use) and IModelBinder (does binding). The
IModelBinderFactory is a new services with coordinates the creation of
model binders.
Ryan Brandenburg
N. Taylor Mullen
Doug Bunting
Jass Bagga
Nate McMaster
Pranav K
Kiran Challa
Ryan Nowak
ivano scifoni
Sebastien Ros
Pavel Krymets
mnltejaswini
jacalvar
David Fowler