Adds new constraints for checking if a route value is a file or not.
Added a new set of builder methods that specify what it means to be a
'fallback'. This is really similar to what the older SPA fallback routes
do, but this is lower in the stack and directly integrated with
endpoints.
This change introduces some new heuristics to make it easier to use
'page' or other resevered parameter names as parameters in URL
generation.
--
The main change here is to allow the link generation tree to *ignore* a
value passed in to URL generation when it conflicts with an endpoint's
required values.
The main concern of this feature area is "how do we tell whether you are
linking to an action or a page?". Routing attempts to do the right thing
will requiring very little from the user in terms of expressing intent.
In this case, we try to tell the difference between an attempt to generate
a link to an action due to the presence of the 'action' parameter and
absence of the 'page' parameter. This obviously doesn't work when you
want to use 'page' as a non-reserved parameter in an action. The same
case occurs for pages, but users are already used to the idea that
'action' is a reserved word in MVC.
We can loosen this restriction when the value that's supplied for 'page'
is known not to be any existing value of the 'page' route value.
This approach seems somewhat reasonable but has many of the problems inherent
to this area. When it fails (the value you want to use for 'page' causes
a conflict) - it's going to be esoteric and hard to understand.
Changes:
* Make Visual Studio 2019 a prerequisite for building this repo
* Update .sln files
* Update Windows SDK to 17134
* Update developer docs
* Disable ANCM tests
* Update to .NET Core SDK 3.0 Preview 2
* Use Microsoft.NET.Sdk.Razor as a package consistently accross the repo
* React to changes in metadata from Microsoft.NETCore.App
* React to changes in .NET Core SDK
* Attempt to workaround CodeCheck.ps1 failure which doesn't repro locally or on different agents. Possibly due to differences in the version of the PowerShell task?
* Remove dead YML file
* Rename usages of win7-{x64,x86} to win-{x64,x86}
* Update KoreBuild to 3.0.0-build-20190219.1
When a `<Reference>` is named `*.Sources`, set PrivateAssets=All (exclude from generated nuspec) and IncludeAssets=ContentFiles (only consume content files, not .dll's)
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'
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.
- 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
- This should allow a more declarative approach to declaring endpoint metadata using the default methods.
- Attributes are applied first and can be overridden imperatively
* Fix#6102 - Intense CPU utilization on page change
The issue here was that every time a Razor Page changed, we would
subscribe an additional time to the endpoint change notifications. This
means that if you tweaked a page 30 times, we would update the address
table 31 times when you save the file. If you were doing a lot of editing
then this would grow to a really large amount of computation.
The fix is to use DataSourceDependentCache, which is an existing utility
type we developed for this purpose. I'm not sure why it wasn't being
used for this already. We're already using DataSourceDependentCache in a
bunch of other places, and it's well tested.
I also tweaked the stucture of this code to be more similar to
EndpointNameAddressScheme. This involved some test changes that all
seemed like good cleanup. The way this was being tested was a little
wonky.
(cherry picked from commit a5658a8c95)
Chris Ross
Ryan Nowak
David Fowler
Justin Kotalik
Nathan
Nate McMaster
Pavel Krymets
JulijaRamoskiene
James Newton-King
Ben Adams
Joni
Hao Kung
Gérald Barré