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)
* 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.
- This completely removes the per request allocation until the feature is used.
- In order to make this change viable, we need to introduce a new HttpContextFactory that can accept new services without adding 2^n constructors. As a result, this change introduces a DefaultHttpContextFactory that takes an IServiceProvider and resolves dependencies based on the needs of the DefaultHttpContext and features.
- Throw in the older HttpContextFactory constructor when the IServiceScopeFactory is null
- It also saves us from revving the feature collection version unnecessarily.
- Today in Kestrel, we reuse the IFeatureCollection per connection and per Http2Stream. This PR aims to take advantage of that same technique and affinitize the HttpContext and friends so that they are only allocated per connection.
- ReusableHttpContext and friends mimic the functionality of DefaultHttpContext but is sealed and has no overridable methods.
- Introduce IHttpContextContainer which allows servers to cache the HttpContext and friends across requests.
.NET Core 2.0 reached EOL last year. This removes multi-targeting our test projects and test assets to only use .NET Core 2.1 and .NET Framework 4.6.1.
This simplifies the way that we publish files to our network drop share.
Changes:
* Instead of explicitly listing every file that needs to publish, use directories to classify packages and artifacts into different categories.
* Add documentation for the expected layout of artifacts/
* Remove the need for static analysis to determine which packages go to which project
* Add the MSBuild property "IsProductPackage" to .csproj files which ship as a package to NuGet.org.
As a result of removing Razor's VS projects and upgrading all projects to netcoreapp3.0, we no longer need dependency variable for .NET Core 1.x and 2.x and Visual Studio packages.
Changes:
* Remove 'StandardTestTfm'
* Remove variables for .NET Core 1.0, 1.1, 2.0, 2.1, and 2.2
* Remove VSIX variables
* Stop generating 'branding.props' - this hasn't been used in a while and is no longer needed
Replaces package references the following packages with local code:
Microsoft.AspNetCore.Certificates.Generation.Sources
Microsoft.Extensions.CopyOnWriteDictionary.Sources
Microsoft.Extensions.ClosedGenericMatcher.Sources
Microsoft.Extensions.ObjectMethodExecutor.Sources
Microsoft.Extensions.PropertyActivator.Sources
Microsoft.Extensions.PropertyHelper.Sources
Microsoft.Extensions.RazorViews.Sources
Microsoft.Extensions.SecurityHelper.Sources
Microsoft.Extensions.StackTrace.Sources
Microsoft.Extensions.WebEncoders.Sources
* Workaround problems when opening solution files in Visual Studio (#4569)
Changes:
* Condense Routing.sln into HttpAbstractions.sln
* Workaround NU1105 by adding all ProjectReferences to the .sln
* Workaround exceptions in the ReferencesHostBridge by moving Reference items to a temporary item group
* Add a 'startvs.cmd' script for launching VS with the right env variables
* Remove RangeHelper test project
* Move RangeHelper tests into StaticFiles.Tests and add target for NPM restore
* Convert Session to use Reference and move to Middleware folder (#4576)
* Add RoutingSample.Web to HttpAbstractions.sln
Changes:
* Condense Routing.sln into HttpAbstractions.sln
* Workaround NU1105 by adding all ProjectReferences to the .sln
* Workaround exceptions in the ReferencesHostBridge by moving Reference items to a temporary item group
* Add a 'startvs.cmd' script for launching VS with the right env variables
* Remove RangeHelper test project
* Move RangeHelper tests into StaticFiles.Tests and add target for NPM restore
Changes:
* Stop producing Microsoft.AspNetCore.Routing.DecisionTree.Sources. I could not find any usages outside of the Microsoft.AspNetCore.Routing assembly, so I've moved this to be a subfolder of code in the Microsoft.AspNetCore.Routing project.
* Stop building src/Routing as a submodule. Use ProjectReference instead
* Move projects from src/Routing into src/Http/Routing/ and src/Http/Routing.Abstractions/
* Update package baselines and dependencies to support building routing projects and samples