Changes:
* Add packages references for EF Core, when necessary
* Add packages references for SpaServices to Spa templates
* Remove PackageReference to Microsoft.AspNetCore.App altogether
See aspnet/AspNetCore#3612 for more context
* Add AccessDeniedPath support to the OIDC/OAuth2/Twitter providers
* Update the code documentation and remove an unnecessary call to SignOutAsync()
* Introduce a new AccessDenied event and move most of the access denied handling logic to RemoteAuthenticationHandler
* Add ReturnUrlParameter support to RemoteAuthenticationHandler
* Remove AccessDeniedException and introduce RemoteAuthenticationHandler.HandleAccessDeniedErrorAsync()
* Use OriginalPath instead of Request.Path
* Update obsolete code comments
* Add unit tests for the new AccessDenied event
* Allow customizing the access denied path/return URL/return URL parameter from the AccessDenied event
* Replace the aspnet/JsonPatch git submodule and merge the master branch of its source to this repo
* Likewise for aspnet/DotNetTools
* And aspnet/HtmlAbstractions
* merge latest infrastructure changes from the release/2.2 branch
- This adds an implementation of IWebHostBuilder as a facade over the IHostBuilder.
This removes the 2 container issue by executing the Startup.ConfigureServies and Startup.ConfigureContainer inline as part of building the IHostBuilder.
- The implementation is highly compatible implementation since it exposes the same IWebHostBuilder interface.
Existing extensions mostly work.
- There are some caveats with this approach.
- Injecting services into Startup is not extremely constrained to the
services availble on HostBuilderContext. This includes the IHostingEnvironment
and the IConfiguration.
- IStartup is broken when using this pattern because it isn't composable.
- The IStartupConfigureServicesFilter and IStartupConfigureContainer The before
and after filters added in 2.1 are also broken because there's a single container (it could maybe be fixed by downcasting and doing something specific on the GenericHostBuilder instance).
- Calling into IWebHostBuilder.Build will throw a NotSupportedException since
this implementation is just a facade over the IHostBuilder.
This changes DataProtection to build as projects instead of a pseudo-submodule. It replaces Package and ProjectReference with <Reference> items which custom targets then resolve.
* Marshal oninput events as UIChangeEventArgs
- Blazor does handle the oninput event, but it is marshalled as a regular UIEventArgs
- This means that we cannot access the new value of the input element from inside our oninput handler
Addresses #821
- use `WaitAny(...)` in inside man
- call `Process.WaitForExit()` twice
- `Flush()` all output `FileStream`s before disposal
- catch `UnauthorizedAccessException` when calling `File.Delete(...)` in case file's in use
- add `/nr:false` to `dotnet msbuild` command line
This allows for scoped instances of `ICorsPolicyProvider` to be injected in the CORS middleware and prevents turning them into singletons.
Resolves#105
The _streams dictionary may not contain the completing stream in
OnStreamCompleted since the IsDraining flag is applied beforehand
which allows it to be removed by the request processing thread.
* Fixaspnet/AspNetCore#3559 Json Patch: System.NullReferenceException while trying to use copy operation from property with null value.
* Fixaspnet/AspNetCore#3559: Missing tests added.
* Pair implementations and unit tests side by side in src/ and test/ folders
* Update .sln and project paths
* Rename unit test projects from Test.csproj => Tests.csproj
* Update KoreBuild properties to allow building projects, not solutions
The _streams dictionary may not contain the completing stream in
OnStreamCompleted since the IsDraining flag is applied beforehand
which allows it to be removed by the request processing thread.
This might help address #3015
This only affects rate timeouts. Normal fixed timeouts might deserve the same treatment, but that would require some additional locking to ensure we don't modify the sentinel value.
Changes:
* This removes MSBuild targets which invoke `docker` commands to build
deb and rpm installers
* Remove installer targets from the KoreBuild context. Put them into
separate project files
* Simplify the targets used to build installers by reducing duplicate
variable names and deeply nested MSBuild contexts
* Remove unused dependencies from the Docker build context
* React to Razor.Design package removal
* Remove references to packages (Razor.Design, Razor.Extensions) solely used to bring in compiler \ targets
* Target netcoreapp3.0 in samples and tests to allow Sdk to infer values
Prior to this, only the response body counted toward the HTTP/2 response data rate. This PR aligns the HTTP/2 logic closer to the HTTP/1.x logic and measures the rate for all HTTP/2 response data.
This PR also accounts for all response bytes written, not just those that immediately induced backpressure.
* Redesign HealthStatus (again)
This change brings back the ability to return Healthy/Degraded/Unhealthy
in a HealthCheckResult. We tried making this pass/fail in 2.2.0-preview3
and folks writing health checks for their own use pointed out (rightly
so) that it was too limited.
It's still possible for the app developer to configure the failure
status of a health check, but it requires the health check author to
cooperate.
I also got rid of HealthStatus.Failed since it raises more questions
than it answers. It's really not clear that it's valuable for a health
check for behave different when throwing an unhandled exception.
We would still recommend that a health check library handle exceptions
that they know about and return `context.Registration.FailureStatus`.
* Cleanup InferParameterBindingInfoConvention
* Infer BindingSource for collection parameters as Body. Fixes https://github.com/aspnet/Mvc/issues/8536
* Introduce a compat switch to keep 2.1.x LTS behavior for collection parameters
* Do not infer BinderModelName in InferParameterBindingInfoConvention
* Convert `RouteValueDictionary` values to `string` using `CultureInfo.InvariantCulture`
- #8578
- user may override this choice in one case:
- register a custom `IValueProviderFactory` to pass another `CultureInfo` into the `RouteValueProvider`
- values are used as programmatic tokens outside `RouteValueProvider`
nits:
- take VS suggestions in changed classes
- take VS suggestions in files I had open :)
Fixes a bug with preview formatting for FAR.
So when we ask the Roslyn API to classify C# for us, it will only
classify the actual C# tokens. We are responsible for filling in the
gaps and whitespace.
The bug is that the following text would have all of its whitespace
removed in the VS FAR preview window.
```
@{ var foo = "Hello, world!"; }
```
Would look like:
```
@{varfoo="Hello, world!";}
```
This fixes the issue and makes it look like what one would expect.
We had a bug where were not returning the correct span for highlighting.
Fixed this.
Also we have a problem here, we're using types in our tests that are
coming from Roslyn - however we're not getting IVT for our test
assemblies. So some additional pain is required.
Fixesaspnet/Diagnostics#511 and aspnet/Diagnostics#514
It's really confusing to people that we use Map. Users expect that the
URL they provide for the health check middleware will only process
exact matches. The way it behaves when using map is not optimal for some
of the common patterns.
- #8593
- also find `IDocumentProvider` using a more-laborious process
- `Type.GetType(string)` requires an assembly-qualified name and we don't know the assembly
- default method name now `GenerateAsync`
- only supported signature is `public Task GenerateAsync(string, TextWriter)`
also:
- handle more error cases in the tool's inside man
- avoid an empty document file if `IDocumentProvider.GenerateAsync(...)` fails
- unwrap an `AggregateException`
nits:
- remove duplicate comments
- change `GetDocumentCommandWorker.TryProcess(...)` to return `false` on failure
- minor because return value is currently ignored
- rename `GetDocumentCommandContext.Output` -> `OutputPath`
- reflect recent change to `dotnet-getdocument`'s `Resources.resx` file in its designer file
This isn't really a test project. It's a class library which contains testing compontents. Because 'xunit' is referenced, IsTestProject=true, which
messes up some of the build logic we have for handling code signing and test runners
As a part of simplifying the way we build ASP.NET Core, the BrowserLink and Scaffolding repos and the packages they produce will be independent from aspnet/AspNetCore.
* Disable package analysis because it incorrectly issues NU5109 on macOS, but not windows
* Normalize file paths because if you mix slashes, NuGet will just skip the entire folder
* Normalize the project path given to restore. If it not normalized, restore skips the project and issues a warning
This removes support for the `--use-browserlink` flag from the templates. The Microsoft.VisualStudio.Web.BrowserLink package will still ship in 2.2, but users who want this should use `dotnet add package Microsoft.VisualStudio.Web.BrowserLink` instead.
* Remove unnecessary \ incorrect package references
* Remove extraneous build outputs in the tasks project that weren't present when the tasks were in Razor.Design
This package does not need to be in the project until someone uses Visual Studio code generation. Visual Studio will automatically add this package when scaffolding is used for the first time, so it's unnecessary to put this in our templates.
This refactors the targets used to build the shared framework and its .zip files. There are lots of reasons motivating this: Arcade convergence, migration to VSTS, making it easier to build this locally, etc.
Changes:
* Moves move content of build/Sharedfx.{props/targets} into eng/targets/SharedFx.Common.{props/targets}
* Update the build to produce a `runtime.$rid.Microsoft.AspNetCore.App` package (not just the one with symbols in it)
* Refactor the targets which produce .tar.gz/.zip files into separate projects in `src/Installers/`
* Refactor installers, unit tests, and the framework projects to use ProjectReference to flow dependencies between different parts of the build.
* Makes it easier to build the shared framework locally (for the inner dev loop, you can run `dotnet build -p src/Framework/Microsoft.AspNetCore.App/src/ -r win-x64`)
This package isn't quite ship-shape yet, so we're delaying this from shipping with 2.2 RTM.
Setting IsPackable=false so we avoid accidentally building a 2.2.0 RTM version of this package along with the rest of the 2.2.0 RTM tools in this repo, like dotnet-watch.
This change implements version tracking the inputs and outputs of
generated code.
Version tracking is still best-effort - meaning that in some cases a
perfect system could avoid doing more work. However, since we base the
versions off of all of the inputs, we now that the guarantee that code
generation operations that happen 'out of order' will always result in
the newer inputs generating the newer outputs.
Fixes: https://github.com/aspnet/Razor/issues/2650
This change adds mock ups of the interfaces that we've been designing as
part of Razor FAR as well as the implementations. This isn't wired up to
anything yet in this PR, but the basic functionality here is stable
enough for us to stabilize and review.
For now we have the interface definitions in the Razor codebase until a
build of Roslyn is available with these definitions + IVT for us to use
them.
This doesn't really accomplish our goals for 2.2 - I don't have a clear
scenario where I would tell a developer to use this VS something else.
Will reevaluate in 3.0
This doesn't really accomplish our goals for 2.2 - I don't have a clear
scenario where I would tell a developer to use this VS something else.
Will reevaluate in 3.0
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