Changes:
* Add support for a property, `IsAspNetCoreApp`, in the .csproj file of assemblies which are part of the shared framework.
* Remove unused dependencies
* Remove reference which have become part of 'netcoreapp3.0'
* [Components] Razor class library for components
* Updates the Razor Class Library to be a portable components library by
default.
* Adds an option to support the old RCL that includes support for Views
and pages.
* Usage:
* `dotnet new razorclasslib` produces the same traditional Razor Class Library.
* `dotnet new razorclasslib -s false` produces a Razor Class Library without views and pages support.
* Relayer MvcEndpointDataSource
Separates the statefulness of the data source from the business logic of
how endpoints are created.
I'm separating these concerns because one of the next steps will split
the MvcEndpointDataSource into two data sources.
* Simplify MvcEndpointInfo
Removing things that are unused and leftovers from the 2.2 design of
this feature.
* Remove per-route conventions
Removes the ability to target endpoint conventions
per-conventional-route. This was a neat idea but we have no plans to
ship it for now.
Simplified MvcEndpointInfo and renamed it to reflect its new purpose.
* Remove filtering from MvcEndpointDataSource
This was neat-o but we're not going to ship it like this. We're going to
implement filtering in another place. Putting this in the data source is
pretty clumsy and doesn't work with features like application parts that
need to be baked in addservices
* Simplify ActionEndpointFactory
* Split up data sources
* Use UseRouting in functional tests
I've rejiggered our functional tests to de-emphasize UseMvc(...) and
only use it when we're specifically testing the old scenarios.
UseMvc(...) won't appear in templates in 3.0 so it's legacy.
* Update templates
* Add minor PR feedback
* one more
This change enhances our ambient value logic to also deal with required
values. In 2.2 we introduced a 'required values' semantic to allow route
values to appear "to the left" of a route pattern for the purpose of
ambient values copying. This is a complicated way of saying "when you
like to a different endpoint then discard the ambient values".
What we didn't consider is that some ambient values are special (like
area). So basically, we'll allow an ambient value to be used if it's
part of the required values - even if we've already decided to discard
the ambient values.
This is a pretty surgical fix and only affected the desired scenario
based on tests.
-----
I also removed an optimization that I think is broken. I put an earlier
optimization in place that attempted to count ambient values as they
were "seen" to try and avoid some extra copying. This copying loop has a
cost even if it no-ops which is what I was trying to prevent.
Unfortunately since we added 'required values' - it's now possible for
an ambient value to be double-counted, which makes this optimization
incorrect.
- Removed ViewsFeatureProvider
- Removed PageArgumentBinder and its internal implementation DefaultPageArgumentBinder.
- Removed corresponding test classes/methods for all the above.
- Reacted to class/member changes in dependencies.
#7326
- Use the array pool by default when the shared memory pool is specified for both the StreamPipeReader and StreamPipeWriter
- Support allocating unpooled memory if the StreamPipeWriter is asked for memory outside of the max pool size
Put transitive external dependencies of the shared framework in a separate category, and don't reference them directly unless we are building a patch. This will help us find changes to dependencies, such as the removal of JSON.NET or possible changes to Crypto.Xml.
Chris Ross
Nate McMaster
Doug Bunting
Pavel Krymets
Hao Kung
BrennanConroy
Pranav K
Javier Calvarro Nelson
David Fowler
Ryan Nowak
Justin Kotalik
Daniel Roth
dotnet-maestro-bot
N. Taylor Mullen
Ben Adams
Doug Bunting
Artak
Martin Costello
kishanAnem
Joni
dotnet-maestro[bot]
Arthur Vickers