- #3918
- precompute size of `StringBuilder` in `ExpressionHelper`
- reduce `string` allocations in `ViewDataEvaluator`
- also get rid of `Enumeration` state machines
- reduce the size of a few objects; use more expression-valued properties
- e.g. don't store `_modelType` in `ModelExplorer`
- add `EmptyArray<TElement>`; make empty arrays consistently `static`
- avoid `string.Split()` in HTML and tag helpers
nits:
- make `ExpressionHelperTest` tests more stringent
- correct `Message` for an `ArgumentNullException`
- remove excess `using`s in classes I touched (but often ended up leaving otherwise unchanged)
- improve doc comments
- remove `ToString()` call on a `string`
- avoid encoding `string.Empty`
- fix test file name
- remove useless variables
- correct spelling
- improve whitespace
This addresses #1051. There is one more pull request that needs to be completed/merged (for `CompositeTagHelperDescriptorResolver` and friends). After that, runtime should work!
- #4690
- move `ModelBindingMessageProvider` init from `DefaultBindingMetadataProvider` to `DefaultModelMetadata`
- in addition to avoiding error cases, this removes some boilerplate
- add specific errors to `BodyModelBinderProvider`, `CompilerCache`, `CompositeViewEngine`, `ModelBinderFactory`,
and `ObjectResultExecutor`
- `DefaultRazorViewEngineFileProviderAccessor.FileProvider` now a `NullFileProvider` in empty case
This change splits up the conventional routing path from the attribute
routing path *inside* routing, instead of inside `MvcRouteHandler`. Each
attribute route group now gets its own instance of
`MvcAttributeRouteHandler` which just knows about the actions it can
reach.
This removes the concept of a route-group-token and removes the lookup
table entirely for attribute routing. This also means that the
`DefaultHandler` on `IRouteBuilder` will not be used for attribute routes,
which we are OK with for 1.0.0.
The action selector's functionality is now split into two methods. We
think this is OK for 1.0.0 because any customization of `IActionSelector`
up to now had to implement virtually the same policy as ours in order to
work with attribute routing. It should now be possible to customize the
selector in a meaningful way without interfering with attribute routing.
- `AdditionalCompilationReferences` is a purely additive option to add `MetadataReference` instances to be used for Razor compilation.
- Added a test to validate the compilation references get combined with the `ApplicationPartManager`s metadata references.
#4497
- Updated `ScriptTagHelper` and `LinkTagHelper` to maintain their quotes on generated script tags.
- Removed `TagHelperOutputExtensions`. It's no longer needed.
- We no longer string replace quotes directly. We rely on encoding and the initial representation of an attribute to ensure quotes don't break generated attributes.
- Updated tests.
- #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.
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.
* Moved instantiation of tag helpers into DefaultTagHelperActivator.
* Introduced ITagHelperFactory for handling the setup of new tag helper instances.
- Simplify things that used to rely on HtmlTextWriter. This behavior is
now the default.
- Simplify a whole mess of Razor TextWriter code.
- Integration test for merging of TagHelper buffers back into the 'main'
buffer.
- #3482
- see new tests; many failed without fixes in the product code
- add support for binding `IFormFileCollection` properties
- make `FormFileModelBinder` / `HeaderModelBinder` collection handling consistent w/ `GenericModelBinder`++
- see also dupe bug #4129 which describes some of the prior inconsistencies
- add checks around creating collections and leaving non-top-level collections `null` (not empty)
- move smarts down to `ModelBindingHelper.GetCompatibleCollection<T>()` (was `ConvertValuesToCollectionType<T>()`)
- add `ModelBindingHelper.CanGetCompatibleCollection()`
- add fallback for cases like `public IEnumerable<T> Property { get; set; } = new T[0];`
- #4193
- allow `Exception`s while activating collections to propagate
- part of #4181
- `CollectionModelBinder` no longer creates an instance to check if it can create an instance
- not a complete fix since it still creates unnecessary intermediate lists
nits:
- correct a few existing test names since nothing is not the same as `ModelBindingResult.Failed()`
- remove a couple of unnecessary `return` statements
- correct stale "optimized" comments
- explicit `(string)`
- aspnet/Coherence-Signed#187
- remove `<RootNamespace>` settings but maintain other unique aspects e.g. `<DnxInvisibleContent ... />`
- in a few cases, standardize on VS version `14.0` and not something more specific
These changes are aimed at significantly improving the performance of
MVC/Razor when a large amount of content is in play or a large number of
TagHelpers are used.
A few issues addressed:
- Buffer sync writes after a flush has occurred so that we can write them
asyncronously. The issue is that an IHtmlContent can only do sync
writes. This is very bad for Kestrel in general. Doing these writes
async is better for our overall perf, and the buffer that we use for it
is from the pool.
- 'Flatten' ViewBuffers when possible. A page with lots of TagHelpers can
end up renting a ViewBuffer and only write 2-3 things into it. When a
ViewBuffer sees another ViewBuffer we can either steal its pages, or
copy data out and 'return' its pages. This lets us use 3-4 buffers for a
large Razor page instead of hundreds.
Ajay Bhargav Baaskaran
Pranav K
Doug Bunting
Ryan Brandenburg
Crystal Qian
N. Taylor Mullen
Ryan Nowak
mnltejaswini
jacalvar
Kiran Challa
Pavel Krymets
David Fowler
Shahriar Gholami
Cesar Blum Silveira