- 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 is the first step, and just estabilishes a skeleton. The end goal
is organize our analyzers under this node because:
1. We're writing some 'top level' analyzers that depend on everything
else
2. We want to be able to service analyzers on the SDK schedule
(independent of runtime).
Next, we'll merge the MVC analyzers into this assembly since there's no
reason for them to be separate. The MVC API analyzers will remain a
separate package, but under this node. The component analyzers will
remain separate as they need to ship as a package, but will move under
this node as well.
Creating a sample for the header propagation package and some various
misc UX improvements based on building the sample.
A small list:
- allow duplicate inbound names
- de-dupe based on outbound names
- add sugar for configuration
- simplify pattern for transforming values
- add error message for missing middleware
Also a few small perf things.
I started this out by wanting to remove the following from the
configuration pattern:
```C#
options.Headers.Add("X-TraceId", null);
```
This pattern with null is undiscoverable, but we didn't provide
something simpler. The most common case was to add a custom collection
type so we can define sugar methods.
The next realization is that in practical case (dist tracing sample) you
either way to *key* off of the same inbound header twice, or you don't
have an inbound header at all, and you will synthesize the value every
time. This means that the way we're treating inbound header names is a
bit wrong. We don't want inbound header names to be unique, we want
*outbound header names to be unique*.
Next, I want to consolidate DefaultValue and ValueFactory. The problems
I saw with this:
- DefaultValue is a trap. It's rare to use a static value.
- ValueFactory really wants the header name *and* value
I think what's there now is much more terse to work with.
* Store component/element keys on RenderTreeFrame
Also refactored how RenderTreeFrame gets constructed. The previous arrangement of having ad-hoc ctor overloads for different scenarios became intractible (too many combinations to avoid clashes; risk of accidentally losing field values when cloning). There's now one constructor per RenderTreeFrameType, so you always know where to add any new field values, and implicitly guarantees you don't lose other field values because adding a new param forces updates at all the call sites.
* Add StackObjectPool, which will be useful momentarily
* Support keyed insertions/deletions
* Refactor AppendDiffEntriesForRange to prepare for adding "move" logic
* Apply permutations on the JS side
* Handle keyed moves by writing a post-edit permutation list
* Shrink KeyedItemInfo struct
* Include sourcemaps when building client-side Blazor apps with ReferenceFromSource
* Update struct length of edit frames now it's explicit layout
It's longer now because all the reference-type fields, except the last, now have to be 8 bytes for compatibility with 64-bit runtimes. Previously on Mono WebAssembly the reference-type fields were all 4 bytes.
* Tolerate clashing keys (i.e., produce a valid diff, even if suboptimal)
* Tolerate keys being added/removed incorrectly
* E2E test harness for 'key'
* Some more unit test cases
* Invert diffing logic to prefer matching by key over sequence
Previously it preferred sequence over key, but that's wrong, and surfaces as bugs when you mix keyed and unkeyed items. We need to prefer key over sequence, because key is meant to guarantee preservation, whereas sequence is just best-effort preservation.
* Make unit test cases more adversarial
* First actual E2E test
* In E2E test, verify correct preservation of components
* E2E tests for simple insert/delete cases (with and without keys)
* E2E test for reordering. Also extend other tests to verify simultaneous editing.
* E2E test for many simultaneous changes
* Update reference sources
* CR: Avoid x = y = z
* CR: Only use 'finally' for actual cleanup
* CR: Clean up RenderTreeFrame assignment
* CR: Include 'key' in RenderTreeFrame.ToString()
* CR: Avoid "new T()" in StackObjectPool
* CR: Make KeyedItemInfo readonly
* CR: Handle change of frame type with matching keys (and sequence)
* CR: Add E2E test showing form + key scenarios
* Preserve focus across edits
* Tweak E2E test case
* In client-side Blazor, prevent recursive event handler invocations
* Actual E2E tests for moving form elements
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.
- aspnet/AspNetCore-Internal#1649
- remove `$(StartArguments}` from project; conflicts with `--update`
- support v3 source _automatically_ when not using `--update`
- use NuGet's V3 source by default
- update README.md
nits:
- `--source` -> `--package-source` due to conflict with a `dotnet` argument
- address Markdown lint warnings in README.md
- grab a couple of improvements from 'release/2.2'
- never exit silently
- remove `first` special case
* EnableAzurePipelinesReporter for helix
* Update Helix SDK
* Revert a fix that broke things even more
* Try publishing test assets
* Try fixing Kestrel tests on Helix
* Try a temp file in the working directory
* Skip Http2Spec tests on Debian 8
* Missed update
* Try a different format
* Disable failing test on Fedora
* Mark flaky test
* Allow ValidationVisitor.ValidateComplexTypesIfChildValidationFails to be configured via MvcOptions (#8519)
* Regenerated reference source for Mvc.Core to add MvcOptions.ValidateComplexTypesIfChildValidationFails
* Simplified functional tests for MvcOptions.ValidateComplexTypesIfChildValidationFails usage scenarios
Larry Ewing
Steve Sanderson
Andrew Stanton-Nurse
Doug Bunting
dotnet-bot
Mikael Mengistu
BrennanConroy
Ryan Nowak
Stafford Williams
John Luo
Justin Kotalik
Ryan Brandenburg
Ben Adams
huysentruitw
Hao Kung
Pavel Krymets
bordecal
Howard Richards