The Arcade SDK requires that the obj/ and bin/ folders be placed in the top-level artifacts/ folder of the repo. Although this PR does not complete our Arcade convergence, this is a step towards updating our repo to build with the Arcade SDK.
Changes:
* Set output path for build to artifacts/bin/$(ProjectName)/
* Set intermediate output path for build to artifacts/obj/$(ProjectName)/
* Cleanup .gitignore files (remove duplication between repo-root and tested gitignore files)
* Add code check which looks for project files that share the same name (could cause issues)
* Rename project files to have unique names (avoid race condition of build output)
* Update all locations which were hard-coded to expect bin/ and obj/ in the project directory
* Add overrides for tests which still assert test binaries exist in a given location relative to the source code
- see #9923 for related discussion
- pin aspnet/EntityFrameworkCore dependencies
- chain aspnet/Extensions dependencies through aspnet/AspNetCore-Tooling instead
- run `darc` to grab the latest
- remove System.Text.Encodings.Web references
- now included in runtime.*.Microsoft.NETCORE.App packages
nits:
- copy a few `ReferenceResolution.md changes from aspnet/Extensions version
This changes the recipe for client-side blazor to use similar primitives
to server side applications.
---
I ignored auto-rebuild support because it's currently dead code until we
have that in VS. If we add auto-rebuild to ASP.NET Core - we'd probably want
to make that a separate gesture inside `IsDevelopement()` like other
dev-time features anyway.
---
The static files hookup is a special thing because creating the file
server for a client-side Blazor app involves some non-trivial work. We
plan to make this better in the future.
What's nice about this pattern is that the implementation is pretty
simple and literal, and it scales fine if you have multiple Blazor
client-side apps.
I didn't provide a lot of options here, it's pretty much the same as
UseBlazor.
---
I feel pretty good about the wireup with routing to use the
`index.html` from the client app. I think it's pretty to-the-point.
* Avoid buffering during input formatting for longer than necessary
EnableRewind uses FileBufferingReadStream which is not disposed until the response is completed.
This results in holding on to internal buffers for significantly longer than necessary. Changing it
to return the buffers immediately improved the allocations and throughput.
Adds functionality to parse a URI path given a way to
find an endpoint. This is the replacement for various machinications
using the global route collection and `RouteData.Routers` in earlier
versions.
For now I'm just adding a way to do this using Endpoint Name since it's
a pretty low level feature. Endpoint Name is also very direct, so it
feels good for something like this.
- This change tries to remove the EndpointSelectoContext allocation by making it a wrapper struct over the HttpContext. Unlike before, the HttpContext gets mutated once any component in the routnig pipeline sets a non null endpoint. This used to happen after the processing was complete.
- This change also implements the IRouteValuesFeature and IEndpointFeature in HttpProtocol to avoid the feature allocation and feature collection version churn.
- We also set the IRouteValuesFeature in IRouter based scenarios.
- Since we're not implementing IRoutingFeature in endpoint routing anymore
we can just create the RouteData inside MVC. We do this by polyfilling RouteData when using endpoint routing inside of MVC
- Implement GetRouteValue in terms of IRouteValuesFeature
- Noop if the EndpointRoutingMiddleware if an endpoint is already set
- Added tests
* Avoid allocations in more cases
Updates to DFA Matcher to avoid allocations in more cases. This makes
the matcher more pay-for-play.
- Avoid allocating an RVD while matching if possible
- Avoid allocating the candidate set unless necessary
First, avoid creating the RVD unless there are parameters or
constraints. This means that the candidate set can contain null route
value dictionaries. This seems fine because selectors are already
low-level. The route values feature will allocate an RVD when accessed,
so code in MVC or middleware won't even see a null RVD.
Secondly, avoid creating the candidate set unless there are selectors.
This will save an allocation most of the time since we won't need to run
selectors is really common cases. The candidate set is needed because
selectors mix mutability and async, so it needs to be a reference type.
However the default case is that we *don't* need to run selectors. The
impact of this is that we make a bunch of methods have an instance
variant and a static variant that operates on the array.
- This change tries to remove the EndpointSelectoContext allocation by making it a wrapper struct over the HttpContext. Unlike before, the HttpContext gets mutated once any component in the routnig pipeline sets a non null endpoint. This used to happen after the processing was complete.
- This change also implements the IRouteValuesFeature and IEndpointFeature in HttpProtocol to avoid the feature allocation and feature collection version churn.
* Update dependencies from https://github.com/dotnet/arcade build 20190423.2
- Microsoft.DotNet.GenAPI - 1.0.0-beta.19223.2
* Adjust to GenApi change in `enum` ordering
- was sorted by name, now by value
This is a crucial enabler for dynamic scenarios. A policy can replace an
endpoint with a *group* of dynamic endpoints which will be disambiguated
by other policies.
This change makes a bunch of random routing classes internal instead of
pubternal. Most of these have no use case and aren't valuable at all
outside of routing code.
The one exception here is that the only way to construct a
`TemplateBinder` in 1.0-2.2 is using a constructor that accepts some
pubternal types. I don't think it's a good idea to just yank this since
the usage is pretty wide.
Instead I added a factory service so you can create this, and marked the
constructor [Obsolete] where these types are touched. We can make the
actual breaking change in the next major release.