This builds support for tracking the effect of changes to imports on
other documents, and completes our model for being able to keep
generated code up to date.
To enable custom handling of antiforgery validation failures, use an
`AntiforgeryValidationFailedResult` which is just a `BadRequestResult`
but allows to be identified explicitly inside always-running result
filters using the `IAntiforgeryValidationFailedResult` marker interface.
Addresses a blocking issue for FAR of types when used in user-code in a
directive. The FAR infrastructure is skipping over the directive code
because it's mapped to `#hidden`. As you can see in the code, the token
provided by the user is already included in the projection mappings.
I think we didn't do this before because we didn't expect this code to
need line numbers - it's not really debuggable, and design-time codegen
doesn't happen when you build the project.
I think it's OK for now that we don't line-map (or include) directives
based on view imports. If you trigger FAR on an `@inject ...` in an
import for instance, you'll find the reference for the view import file.
That seems pretty good, and the only cases I can really imagine it being
broken would be for go-to-definition (within a Razor view). Lets revisit
in the future based on feedback.
* Add Remove(string key, out object value) overload to RouteValueDictionary.
* Consistently use _count field instead of Count property in Remove overloads.
Added comment on EnsureCapacity call.
Added test for removing first/middle/last entry.
- Prior to this project changes would trigger re-parses which would then be thrown away because source versions were identical.
- Added test to verify new SetOutput behavior.
aspnet/Razor.VSCode#184
There are legitimate use cases for referencing BCL assemblies that *aren't* in the Mono WebAssembly BCL, particularly for Blazor-on-the-server which runs on CoreCLR (and hence supports a broader BCL) anyway.
* Add Provider component
* Implement discovery and matching rules for tree parameters
* Remove artificial component hierarchy unit tests now they are redundant
* Refactor: Have RenderTreeFrame point to the ComponentState instead of IComponent
... so we can more quickly find associated tree param state without having to do lookups based on the componentId.
Also rename AssignComponentId to AttachAndInitComponent to be more descriptive.
* Refactor: Add shared code path for updating parameters so there's only one place to attach tree parameters
Now framework code should no longer call IComponent.SetParameters directly, except if it knows it's definitely dealing with a root component.
* Refactor: Simplify Parameter by making it hold the name/value directly
This will be necessary for tree parameters, which don't correspond to any RenderTreeFrame
* Refactor: Wrap ParameterEnumerator logic in extra level of iterator so we can also add one for iterating tree params
* Extend ParameterEnumerator to list tree parameters too
* Include tree parameters in SetParameters calls
* Refactor: Move parameter change detection logic into separate utility class
... so we include https://github.com/dotnet/jsinterop/pull/3
* Refactor: Move tree parameter tests from RendererTest.cs their own file
* Have Provider re-render consumers when value changes. Unit tests in next
commit.
* Components that accept tree parameters need to snapshot their direct params for later replay
* Empty commit to reawaken CI
* CR: Make name matching case-insensitive
* Refactor: Rename Provider/TreeParameter to
CascadingValue/CascadingParameter
* Add dedicated [CascadingParameter] attribute. Remove FromTree flag.
* CR: CascadingParameterState cleanups
* CR: Extra unit test
* CR: arguments/parameters
* CR: Enumerator improvements
* Fix test
This change does 2 things:
- It disables the websocket keep alive since SignalR has its own bidirectional pings. This should remove a significant timer overhead per WebSocket connection that we end up with today. We have a single timer that sends to all connection on an interval.
- Don't pass the CancellationToken to ReadAsync in the handshake since the Pipe implementation holds onto the token for longer than it
needs to which keeps Timer objects alive (see dotnet/corefx#32806)
I found this when reading the source code and looking at dumps of a couple of SignalR applications.
This ensures that JSON patch "replace" operations are functionally
equivalent to "remove" operations followed by "add" operations at the
same path, as RFC 6902 specifies.
Addresses #110
* Add build definition for Azure DevOps
* Put code for metapackages in a subfolder
* Update targets to prepare for submodules merging into this repo
* Add source code for windows installer
* Add source code for Debian installers
- #8428
- add signing-related and PackageVerifier configuration for new package
- remove packaging configuration from dotnet-getdocument project
- adjust `dotnet-getdocument` invocation to its new location
- remove use of nonexistent (ignored) `dotnet-getdocument --no-build` option
Remove `--uri` feature from `dotnet-getdocument`
- reduce dependencies from Microsoft.AspNetCore.TestHost to Microsoft.AspNetCore.Hosting.Abstractions
- assume web site depends on that
- merge `DownloadFileCore` into `DownloadFile`
- remove other unecessary code e.g. `WrappedException` was never `throw`n
Correct issues in `DownloadFile`
- e.g. dispose of `responseStream`, use `await` more, support FIPS-compliant machines
nits:
- clean up `Project` and the metadata it fetches
- remove unnecessary `.props` and `.targets` files
- follow-ups to 1646345955 and 9d109f5956
- fix `%(Command)` updates in `DefaultDocumentGenerator` target
- later references to metadata values set within an item are not up-to-date
- qualify values for `%(SourceProject)`, `%(SourceUri)` and `%(SourceDocument)` when setting that metadata
- MSBuild can't distinguish unqualified metadata references unless using `<X Update="@(X)">`
- fix `@(CurrentServiceFileReference)` items
- was a copy 'n paste error in `_ServiceFileReferenceGenerator_Core` target
- remove per-language default namespace values
- do not add TypeScript files to `@(Compile)`; generally enhance final item additions
- use `$(DefaultLanguageSourceExtension)` to help here
- exclude generated source files with `%(OutputPath)` that does not match `$(DefaultLanguageSourceExtension)`
- really support `%(OutputPath)` directories
- stick with current `$(TargetFramework)` when building `...ReferenceGenerator_Inner` targets
- `%(ProjectTargetFramework)` will not exist for all `@(ServiceFileReference)` items
- building the current project, not a service project; `%(ProjectTargetFramework)` may not be supported
nits:
- shorten a few more long lines in Microsoft.Extensions.ApiDescription.Client.targets
- reduce logging from that file
- do not include `%(SerializedMetadata)` in `%(SerializedMetadata)`
- caused extra-long serialization of items that were originally `@(ServiceProjectReference)`s
- add more info to various comments
- always use element syntax for metadata additions
- related to #8419 and (more generally) #7947
- add errors for missing required metadata
- add errors for duplicate `%(DocumentPath)` and `%(OutputPath)` metadata
- remove `[Required]` for task inputs that may be `null` or empty
- correct `%(DocumentPath)`s generated in `GetProjectReferenceMetadata` task
- use this task
- #8419
- perform batching and `@(ServiceFileReference)` and `@(Compile)` additions in common code
- take advantage of new simplicity in `DefaultDocumentGenerator` target
- add metadata serialization / deserialization in support of passing items into `<MSBuild />`
- also ensure metadata values are escaped before calling `ITaskItem.SetMetadata(...)`
- correct typos in Microsoft.Extensions.ApiDescription.Client.* e.g. in comments and metadata names
- move last remaining `GenerationTasks` file
nits:
- combine `_ServiceProjectReferenceGenerator_Restore` and `_ServiceProjectReferenceGenerator_Build` targets
- only build web sites projects once
- remove unused `buildMultiTargeting` targets
- remove qualification of metadata listed in an `<ItemDefinitionGroup />`; will always exist
- add / remove a few `Condition`s that were missing / redundant
- move properties users won't normally set to Microsoft.Extensions.ApiDescription.Client.targets
- shorten lines in MSBuild files
- use same generator as most other projects in aspnet repos
- were not using named arguments to resource methods anyhow
- update resources to use regular (numbered) format parameters
- adjust to new `Resources` namespace; no need for separate `using`
- use `Format...(...)` methods as necessary
- also cleared out most uses of `GetDocument` and `GenerationTasks` in MSBuild and strings
- temporarily fixed up T4 templates, adding Resources.tt (will remove custom generation soon)
IHealthCheckPublisher allows you to configure and run health checks
regularly inside an application, and push the notifications elsewhere.
All publishers are part of a single queue with a configurable period and
timeout.
Fixes a few issues with how we initialize the middleare.
- Always completes the intitialization task
- Avoids capturing the ExecutionContext
- Allows initialization to occur repeatedly when it fails
This allows us to filter `IEndpointSelectorPolicy` instance based on
whether the apply to a given candidate set. This should allow us to
remove some HAXXX from MVC.
The idea here is the ESP becomes much more pay-for-play if you can
statically eliminate many of the cases where it would usually no op.
* #2230 Mark ServerAddress as obsolete
* #2230 suppress CS0618 errors for obsoleted ServerAddress class
* #2230 Use BindingAddress instead of ServerAddress
- Improve test reliability of tests verifying the RequestAborted token gets tripped
- Once the response body is completed, don't fire the token for that request even if it is accessed later on.
- should resolve issues with occasional strange MSBuild caching issues in this repo
- modeled after aspnet/Scaffolding#905
- follows aspnet/BuildTools#729 recommendation to check in global.config file
- see also Microsoft/msbuild#2914
- use newer KoreBuild
- `.\build.cmd -update /t:noop`
We currently build .deb files using dotnet-deb-tool, which comes from a package feed. We're not completely sure where the source code is for this tool, so this moves the scripts from the dotnet-deb-tool 2.0.0 package into this repo for safe keeping.
1. Prevent an ObjectDisposedException in dotnet-watch on slower machines
2. Fix flakiness caused by PID reuse
3. Fix flakiness in tests that await the restart of dotnet-watch. The `.TimeoutAfter` method doesn't cancel the long-running task. This left 2 readers running on dotnet-watch output which caused indeterminate test outcome.
* remove sources.props and use NuGet.config. Source.props is only necessary for products that bulid in ProdCon, which Blazor does not
* Remove code signing glue code. This is part of KoreBuild now
* Update SDK to 2.1.400
* Update certificate names used for code-signing to use SHA2
Adds logging for the most common things that can prevent an endpoint
from matching.
Note that we already have good logging in other parts of the system, the
stuff here completes the story by providing details at the debug level.
* Added execution time duration into HealthReportEntry and TotalDuration on HealthReport
* review PR feedback from @rynowak.
* added the same duration into HealthReportEntry and log when the health check throw
* Include the response type in ProducesResponseType for client errors
* Refactor ActualApiResponseMetadata discovery in to a separate more manageable type
* Annotate action result ctors and helper methods that specify the "object" value with attribute
* Modify the discovery of parameters to match ActionResultObjectValueAttribute and ActionResultStatusCodeAttribute by name
to allow users to write and annotate custom helper methods and action results, a la NotNullAttribute.
Fixes#8345
Adds support for 'Context' parameters on components
This change allows you to set the parameter name of a parameterized child content by using the `Context` attribute on the component. The `Context` attribute will be defined (and shown by completion) when the component has one or more declared parameterized (`RenderFragment<>`) child content parameters.
This is nice for cases where you are using implicit child content:
```
<ol>
<Repeater Items="People" Context="person">
<li>@person.FirstName</li>
</Repeater>
</ol>
```
or, when you have multiple child content elements and want them all to have the same parameter name:
```
<MyComponent Items="People" Context="person">
<ChildContent1><div>@person.FirstName</div></ChildContent1>
<ChildContent2><div>@person.LastName</div></ChildContent2>
</Repeater>
```
The parameter name can be overridden by using the `Context` parameter on the child content element:
```
<MyComponent Items="People" Context="person">
<ChildContent1 Context="item"><div>@item.FirstName</div></ChildContent1>
<ChildContent2><div>@person.LastName</div></ChildContent2>
</Repeater>
```
If the component defines a `Context` parameter already then we won't synthesize one - your component's parameter will work exactly as it did before this feature.
- Resolve the logger from the right service provider to log duplicate hosting startup assemblies.
- Don't create a 3rd IServiceProvider if we resolved the default implementation.
* Fix#1298
This change lifts our Razor dependencies to 2.1.1. This is needed
because by default ASP.NET Core projects will depend on 2.1.1 - which
results in a conflict trying to use the Blazor compiler. The Blazor
compiler will load the 2.1.0 msbuild tasks, which then break loading the
2.1.1 tasks.
Since this is happening in the MSBuild process, we can't really write
any code to sort this out. We have to make sure the versions match.
In general the guidance for ASP.NET Core is that projects will **compile
against** 2.1.1 so this won't be a problem in the future unless a user
project specifically lifts ASP.NET Core to a higher version. If that's
the case they will also have to live `Microsoft.AspNetCore.Razor.Design`
to match.
We weren't correctly recovering when a void element is written as a
start-end pair. This change cleans up some of the plumbing around
end-tag handling and adds recognition for this case.
Added a new bespoke diagnostic for the void element case.
- #8180
- add an error when binding fails for top-level model
- same case as when MVC creates "default" / empty model i.e. `ParameterBinder` can't detect this
- update `CollectionModelBinder` subclasses and the various providers as well
- controlled by existing `MvcOptions.AllowValidatingTopLevelNodes` option
smaller issue:
- change `ModelBinding_MissingBindRequiredMember` resource to mention parameters too
This change skips our 'temp' compilation that we do to implement 2-phase
build for defining components in .cshtml when the project is not C# OR
when the project has no .cshtml files.
This should make the rest of the build-time Blazor functionality work
for non-C# projects.
This should also make the build faster when you have the Blazor targets
imported in a C# project with no .cshtml files.
This change allows you to use generic-typed components without
explicitly specify type arguments.
**Before:**
```
<Grid Items="@MyItems" TItem="Person">
...
</Grid>
```
**After:**
```
<Grid Items="@MyItems">
...
</Grid>
```
Where possible, the type of the component will be inferred based on the
values passed to component parameters. This won't work like magic, you
have to specify parameters that provide type arguments for all of the
component's type parameters.
This is a best effort system, and it's largely based on the limitations
and behaviours of generic type inference in C#. We think it will work
well with most Blazor features and for most reasonable components. You
should not forget it's easy to specify type arguments, because you may
still have to in some cases.
In particular you may notice issues if you are trying to use a generic
typed component where all of the parameters are delegates or templates.
Type inference for delegates/lambdas in C# is based on the context. Any
time you combine generics and delegates it's easy to get into a scenario
where the compiler won't infer the correct type, or will give up.
----
The type inference feature works by generating a 'thunk' method in
*caller* that can act as a site for type inference (C# does not support
inference on constructors).
For our grid example above, the non-inferenced code will look something
like:
```
builder.OpenComponent<Grid<Person>>(0);
builder.AddAttribute(1, "Items", MyItems);
builder.CloseComponent();
```
Note that we can only write the type `Grid<Person>` because you wrote
`Person` in your code. What you type in the `TItem` attribute value gets
inserted into the generated code such that it fills in the generic type
parameter.
On the other hand, if you want is to infer the type, we have to do some
compiler magic. That looks like:
```
__Blazor.(long generated name).TypeInference.CreateGrid_0();
...
// elsewhere in the file
internal static class TypeInference
{
public static void CreateGrid_0<TItem>(RenderTreeBuilder builder,
int seq, int __seq0, global::System.Collections.Generic.List<TItem>
__arg0)
{
builder.OpenComponent<Grid<TItem>>(seq);
builder.AddAttribute(__seq0, "Items", __arg0);
builder.CloseComponent();
}
}
```
This allows us to rely on the C#
compiler for itype inference.
- Rename -> IOutboundParameterTransformer
- Make it operate on object
- Implementing caching for constraints/tranformers for link generation
(cached as part of TemplateBinder)
* Fix wiping assemblies that contain references to others in same directory
* Fix generated IL for reporting calls to wiped methods
* Add E2E test for method wiping
* Use options for registering health checks
This change pivots to use options for registering health checks. We get
a few pretty nice things out of this, and it unblocks some of our
requirements.
Now all registration methods support the application developer
configuring the name, failure-status, and tags for each health check.
This is a requirment, that we weren't really satisfying - which is what
led to this redesign. In support of this health checks now return pass/fail,
and the service is responsible for assigning the status.
----
Health check authors that need configuration data (connection string as
an example) now have three ways to do this depending on their
requirements.
1. Create an instance and register that (easiest)
2. Use Type Activation and pass parameters (middle)
3. Use named options (richest)
We expect most health checks to need/want some kind of configuration -
which 1) works pretty well to solve. However many other health checks
will need DI + configuration. It was also a gap that we didn't have a
good way to use named options, when it's such a good fit for our
scenarios.
Added new registration methods for type activation that allow you to
pass parameters for 2).
Added a context type that allows the running health check access to its
registration for 3).
----
Redesigned and renamed how status gets reported. Health checks return
pass/fail result, but the overall HealthReport includes entries of a
different type. This seems fine because there isn't really a way to
consume a HealthCheckResult directly - the service is the only consumer.
----
Added support for tags. This was easy to add now that we have a separate
registration type, and it's quite handy for building filters (see
sample).
* HARDER BETTER STRONGER FASTER
This allows users to use `ProducesAttribute` to specify the content-type
for action results such as FileStreamResult where the result determines the content type
and the specified value is informational.
Fixes https://github.com/aspnet/Mvc/issues/5701
Loading multiple versions of a task assembly result results in MSBuild on .NET Core to fail.
Addressing this by moving the tasks in to the Sdk and renaming it. This should avoid
immediate issues for a 2.1 and 2.2 project co-existing and future proofs 2.2 and later.
Fixes https://github.com/aspnet/Razor/issues/2553
- #7562 part 2
- add `OriginalModelName` to `ModelBindingContext`
nit: take VS suggestions, mostly to inline collection initialization in `FormFileModelBinderTest`
* Add the ability to discover generic types/properties
* Add @typeparam directive
Adds the ability to declare a generic-typed component using Razor.
* Add a 'type parameter' property to generic components
* Adds the ability to consume generic-typed components
- Print out the raw handshake payload as utf8 text if it fails to parse as JSON or if we're missing properties. This should help flesh out potentially buggy clients.
Change tokens can call into your code IMMEDIATELY when you subscribe. I
reviewed our other usage of ChangeToken.OnChange in MVC and everything
looks good.
* Move startup action config into AddServerSideBlazor, so that UseServerSideBlazor is reduced to trivial shorthand that can become optional
* Make BlazorHub public so developers can use it with UseAzureSignalR
* Move BlazorHub to Microsoft.AspNetCore.Blazor.Server namespace for easier consumption
* Add notes
* Have E2E tests validate that devs don't have to call UseServerSideBlazor
* Add forgotten tweak
* CR: Document that BlazorHub methods are not intended for application use.
* CR: Rename extension method to UseSignalRWithBlazorHub
* CR: TryAdd
* Test namespace cleanup
* Add recognication for RenderFragment in tag helpers
* Remove dead code from node writers
* refactor type check
* Continue to treat child content as a delegate in codegen
* Add extension to enumerate child content
* Reorganize code generation tests
These were growing a bit disorganized, and weren't really result in good
code reuse.
* fix test base class
* Add some child-content tests
* Add an explicit node for ChildContent
Adds a strongly typed node to represent a 'ChildContent' and what it
contains. This allows us to simplify the code generation path,
detect/processes more issues in IR passes, and will be essential for
supporting multiple child content.
* Ignore ChildContent in components when it's just whitespace
* Add diagnostic for duplicate child content
* Add support for explicit child content elements
Precursor to support for multiple child content items
* Add support for multiple child-content elements
* Change delegate signature for RenderFragment<T>
* Clean up Tag Helper constants
* Allow RenderFragment<T> as a child content
* Allow renaming the template parameter
* Improve error message for invalid child content
* Add diagnostic for repeated child content parameter names
- Prior to this we had a `BackgroundDocumentGenerator` that would constantly be updating generated code containers. With this changes we've changed the details in how a `GeneratedCodeContainer` can be mutated. It can now be touched from any thread and is updated when an underlying `DocumentSnapshot` has available content. However, if a generated output comes through that's older then the last seen output we no-op.
- Removed `BackgroundDocumentGenerator` SetOutput logic.
- Updated tests to react to new behavior of `GetGeneratedOutputAsync`.
- Added new test to verify getting generated output results in the setting of the host documents output.
Currently MVC is still running the IActionConstraint implementations for
features that we've already moved into the routing layer. This has a
significant perf cost associated with, and so we want to skip it because
it's redundant. However if anyone has implemented their own
`IActionConstraint`-based features, they still need to just work.
This change takes the approach of skipping the action constraint phase
at runtime unless we see something 'unknown'. This is an all or nothing
choice, and will run action constraints if **any** action constraint we
don't special case exists. This is the most compatible behavior (running
redundant constraints) when the application is using constraints that
the developer implemented.
Another approach I considered was to eliminate these constraints as part
of the process of building ADs. I don't think that's ideal because
people have written code that introspects action constraints. We should
consider something like this in 3.0.
* Un-Map IPv4-to-IPv6-Mapped ips before comparing to known proxies/networks. Addresses #358
* Checking both mapped and unmapped versions of IPv4toIPv6 ips. Addresses #358
* Confirm IPv4toIPv6 mapping/unmapping. Addresses #358
Validates that the type used as a generic argument in WebApplicaitonFactory is contained within the entry point to assembly and throws InvalidOperationException otherwise
* Add "ilwipe" build command
* Perform BCL wipe as part of build
* Simplify by converting ilwipe command to process entire directories
* Clean up the build
Adds support for Razor templates and RenderFragment<T>.
Razor templates are a little-known Razor feature that looks like:
```
@<tag>....<tag>
```
It's so little known that it's not even covered in our docs, but it's
been around for many many years. This features hasn't been implemented
until now for Blazor, and this feature brings it back as a build
building block for templated components (more to come).
In Blazor land a template like:
```
@{ RenderFragment<Person> template = @<div>@item.Name</div>; }
```
complies to code like:
```
RenderFragment<Person> template = (__builder, item) =>
{
__builder.OpenElement(...);
...
__builder.CloseElement(...);
}
```
Since the declaration always has a generic type parameter inside, it
needs to be in a context where the type is known.. ie: not with `var`.
See tests for ways to consume templates.
NOTE: There are the following caveats for templates
- Templates require a single root element.
- Templates don't work in the `@functions { }` block
These limitations are baked into the core of Razor and will take a while
for us to address (v3.0).
* Allow health checks to use any DI lifetime
This change allows registered IHealthCheck implementations to use any DI
lifetime. This is necessary for scenarios like using EF which requires a
scope.
The works by having the health check service create a scope for each
time it queries health checks. This scope does not overlap or share
state with other scopes (the request scope) so there is no crosstalk
between processing going on per-request in ASP.NET Core and the health
check operation.
* PR feedback and some logging cleanup
- The issue was that the `executeChildContentAsync` call was stopping the invocation of the `_endTagHelperWritingScope`. Therefore, we'd never finish the TagHelper content scope and all following content would be ignored.
- Added two tests to validate the new functionality.
#2561
When a project is created with ExcludeLaunchSettings enabled, set the
NoDefaultLaunchSettingsFile property to prevent Visual Studio from
creating a launchSettings.json.
* Remove JSInterop files from this repo
* Add jsinterop submodule
* In Blazor.sln, reference jsinterop projects from submodule
* Update other references to jsinterop
* Fix TypeScript warning
* Include submodules in test/pack
* Update to newer jsinterop to fix JS pack issue
* Update to newer jsinterop to obtain strong naming
* Allow jsinterop submodule to inherit Directory.Build.props/targets
* Get latest jsinterop
* For AppVeyor builds, restore git submodules (happens automatically elsewhere)
* Update README.md with instructions to restore submodules
* Don't preserve the ExecutionContext when dispatching callbacks
- The layers up stack already preserve and restore the ExecutionContext, there's no need to capture and run for the scheduler callback and cancellation token callback
I think something that was meant to be revisited in a PR got left
behing. I found this while fixing aspnet/Routing#772 and it seems worth
addressing.
This change removes the hardcoding of action/controller/area in the
data source, and corrects the behavior of required route values when
they aren't in that set.
- Multiple things capture the ExecutionContext, reduce the changes of improperly rooting the HttpContext when we only need a few properties from the request.
Content MSBuild items from the ClientApp directory are removed from
the project using an MSBuild and then all files are added as None
items. None items that were added by the .NET Core SDK default MSBuild
items were not being removed from the ClientApp directory. This
resulted in duplicate files shown in Visual Studio for Mac. This
affected all the SPA project templates.
Fixes#559
- Avoid race where a connection reset observed by both DoSend() and DoReceive()
resulted in a ConnectionAbortedException being thrown from the input Pipe
instead of a ConnectionResetException.
If another handler modifies the request headers the modified headers get
applied on subsequent requests, which is not correct. This change copies
the headers before sending the request and uses the original headers for
the redirect request instead of the potentially modified ones.
This change makes the handling of graceful shutdown work for more than just http scenarios. This should allow us to move TLS further out and should also allow us to start moving things to connection middleware instead of connection adapters.
Summary of the things changed/added:
- Added IConnectionLifetimeNotificationFeature that represents an attempt to gracefully close the connection that isn't being aborted. This feels pretty awful but we may have to do it.
- Moved connection management to the ConnectionDispatcher and out of the HttpConnectionMiddleware
- Removed Http from the names of the ConnectionManager and Heartbeat
These changes are based on our discussion earlier this week. Adding
async, and making it possible to short circuit, which should be better
aligned with the requirments of versioning.
We recommend using this package with PrivateAssets=all everywhere to
make sure that the MSBuild files brought in by this package aren't
applied to transitively.
When that happens, the Blazor.Build MSBuild files will take over the
Razor functionality for other projects, which breaks MVC's view
compilation functionality.
This is part of a fix for #1216.
* Auto generate CSharp syntax tree nodes
- Auto generated syntax nodes, visitors and factories
- Renamed RazorComment to RazorCommentLiteral to avoid a conflict
- Modified the Visit() contract
- Added new SyntaxKinds
- Regenerated baselines
This code previously was in private repos because it had references to internal locations and drop shares. This code has been modified to remove these internal-only pieces.
* Updated the tokenizer and parser to operate on SyntaxTokens directly
- The tokenizer and parser now operates directly on SyntaxTokens (Green)
- The SyntaxToken(Red) is now created when the Span is built with the correct parent and position
- All other passes that run after the parsing is complete(TagHelperRewriter etc) will operate on the Red tokens.
- There is now only one type for all SyntaxTokens. They are differentiated by their SyntaxKind.
- Added equivalence checking for tokens
- Updated test code to react
- Regenerated baselines
- Include hosting logs in some tests that where previously missing them
- Prevent duplicate logs from Mock CallBase an CompositeKestrelTrace
- Log ports used by transport functional tests
- Add file logging to HTTP/2 "unit" tests
The new Formatter is used in debugger display, to resolve#2264
The next iteration (assuming we like this) will be to replat our testing
baseline infrastructure on top of this, and then start sharing that with
Blazor - related to #2265.
I found when implementing debugger display that I was duplicating a lot
of details between testing and this.
I also want to convert the Blazor tests to use shared infrastructure.
Right now the Blazor tests use a modified version of the Razor
infrastructure that has different features.
Initial infrastrucure for a better html parser
- Added new syntax node types that follow Roslyn's red/green pattern
- Modified the html text node in the current syntax tree to use the new
nodes
- Updated test infrastructure
- Generated baselines
This change adds the ability to merge sibling nodes when possible during
markup block rewriting. We retain that invariant that each markup block
is a valid chunk of markup containing properly nested tags.
We still haven't done any work to remove whitespace yet, so most of the
cases where this comes into play right now will merge an element with
its surrounding whitespace.
* Reenable HtmlBlock unit tests
* Add E2E tests for HTML Block cases
* Remove harded GenerateBaselines=true
* Fix#1193
This commit addresses the root cause of #1193. When we merge HTML
text nodes into HTML blocks we need to re-encode any HTML entities that
were encoded eariler.
I did a bit of a deep dive on how HTML encoding is handled in Blazor and
I think this is the best strategy. I think it's valuable that the
BrowserRenderer uses document.createTextNode, which will always encode
the text - this handles dynamic content. We want to keep this in place
to avoid HTML injection attacks.
* Fix#1265 Reenable MarkupBlock
* test cleanup
- Migrated the completion item source provider and the legacy directive completion provider to use the new service.
- Cleaned up duplicate tests that were both verifying common completion functionality.
- Ensured that the legacy `RazorDirectiveCompletionProvider` did not result in additional Razor assembly loads when in C# scenarios.
#2530
In the `angular-cli.json` file, the styles.css file should be imported last in the styles section, so the developer can override styles from third party libraries (bootstrap, in this case).
- Kept the same behavior as we previously had with Razor directive completions.
- Attempted adding additional functionalities such as lighting up Razor directive completion when completion was invoked on top of Razor directives (non-C#) but ran into issues involving the core HTML editor not consuming the new completion APIs yet. That's something we'll have to re-visit once they move to the new completion APIs.
- Added tests to validate all aspects of new completion APIs.
- Made completion provider turn on and off based off of feature flag.
#1743#1813
Both UnsupportedContentTypeFilter and ModelStateInvalidFilter use ModelState to
determine the response. UnsupportedContentTypeFilter returns a more specific
response and should execute earlier than the latter filter.
Fixes#8236
* SocketSenderReceiverBase as baseclass for SocketSender and SocketReceiver
* Made SocketAwaitable.GetResult inlineable
* SocketAwaitable renamed to SocketAwaitableEventArgs and inherited from SocketAsyncEventArgs
Thus saving an extra object (`SocketAwaitable`) and two int-fields, so less allocations.
* Change project layout to prepare for upcoming Arcade changes
* Add signtool config file to configure OPC, NuGet, and Authenticode signing
* Fix a bug when BaseIntermediateOutputPath is set to an absolute path
* Make un-graceful shutdown a bit more graceful
- Change how graceful shutdown is done to ensure there are no errors on shutdown.
- Avoid closing pipes from under other components that own those pipes.
- Close the application output so that the application's read loop ends gracefully. For websockets, we cancel the token, for other transports, we close the output directly.
- GetTickCount() is limited to the resolution of the system timer, which is typically 10-16 ms. If two apps in separate app pools are started within this time window, it's possible GetTickCount() will return the same value, which causes the apps to try the same random port(s).
- Addresses #1124
Default to requerying swagger for each exec
Auto-set the content-type if not yet set for requests based on swagger
Fix swagger UI command
Make error and warning colors configurable
Allow aliases to be specified in structured input based commands
Have delete not require a body
Show allowed methods for . and ..
Show verbs on the announced path after CD
Issue a request on set base and warn if there's a socket error
This adds UseHealthChecks overloads that configure the health checks
middleware to listen on a preconfigured port.
This is sugar for MapWhen, but it's important because a significant set
of users will want to use Health Checks in this way.
This adds UseHealthChecks overloads that configure the health checks
middleware to listen on a preconfigured port.
This is sugar for MapWhen, but it's important because a significant set
of users will want to use Health Checks in this way.
* Remove JSON output and convert to sample
GlennC and I made the decisison to turn the JSON output into a sample
rather than something we support out of the box. We wouldn't tell
customers to definitely use it and we don't want to introduce more
coupling to JSON.NET.
Pagination hasn't been dealt with yet
mac keybindings may be able to be simplified, pending some additional verification
Fix 3rd party signing cert
Bind a few common bash/zsh mappings
Check for output redirection
Make package version variable name consistent
Add --help option for the command line
Remove regions
Remove old pointer resolution code
Make command not found message more friendly
Fix issue where base address was required for requests to absolute URIs
Add options to suppress response formatting and streaming
Turn off packing for the REPL project
This allows each middleware to be configured with a specific set of
checks (by name). See the comments in the sample for how this is
frequently used.
This is also addresses aspnet/Home#2575 - or at least the part that we
plan to do. We think that any sort of built-in system of metadata or
tags is vast overkill, and doesn't really align with the primary usage
of health checks.
We're providing building blocks, and these can be put together to
build more complicated things like what's described in aspnet/Home#2575.
A bunch of small changes and updates for 2.2 focused at making our main
scenarios more streamlined and focused. Also adds samples for
extensibility we support so far.
A list of changes:
Clearing baselines for these projects. We didn't ship anything in 2.1 so
there should be nothing in the baselines.
--
The middleware now uses Map for path matching. This makes the actual
`HealthCheckMiddleware` more standalone. This will make it easy to use
with Dispatcher/Endpoint Routing in the future.
This also manifests by removing Path from HealthCheckOptions - the path
is an explicit argument to the UseHealthChecks middelware - this
streamlines the design for 3.0.
--
Added extensibility for customizing the status codes (aspnet/Home#2584)
--
Added extensibility for writing the textual output (aspnet/Home#2583)
--
Changed the default output to be `text/plain`. The most common use cases
for health checks don't include a detailed status.
The existing output format is still available as an option.
James Newton-King
Gert Driesen
Ryan Nowak
Chris Ross (ASP.NET)
N. Taylor Mullen
Nate McMaster
Pranav K
Patrick Westerhoff
Pavel Krymets
Justin Kotalik
dotnet-maestro-bot
Chris Ross
Steve Sanderson
Meir Blachman
Lukas Bickel
John Luo
MK
itminus
MikaelMengistu
Ryan Brandenburg
Javier Calvarro Nelson
David Fowler
David
Stephen Halter
Peter Blazejewicz
Hao Kung
Doug Bunting
Turner Bass
BrennanConroy
Ben Adams
Günther Foidl
David J. Quiroga
George Drak
Luke Latham
Jo Ham
Andrei Amialchenia
Nate McMaster
Alexej Timonin
Daniel Roth
Brian Chavez
Ryan Nowak
Simon Cropp
Unai Zorrilla
Roma Marusyk
andrewslavin
Tomasz Jaskula
KristianJakubik
melnikov77
Mike Harder
tiago-soczek
Daniel A. White
Suchiman
Rick Anderson
Andrew Stanton-Nurse
Glenn Condron
Joni
Sebastian
gqqnbig
Andrii Kurdiumov
Casey O'Brien
Takaaki Suzuki
Hassan Hashemi
cores-system
Kristian Hellang
dan.s.ward
Chris Ray
Alfred Myers
Mike Lorbetske
Ajay Bhargav Baaskaran
Massimiliano Donini
Matt Ward
Ajay Bhargav Baaskaran
Christer van der Meeren
Kiran Challa
Thomas Levesque
Wilson
kishanAnem
Marcin Burak
Artak
unknown
uazo
Arthur Vickers
Ryouko Konpaku
Gordon Beeming
Kiran Challa
Artak Mkrtchyan
Scott Addie
Wraptor