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
- #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.
Pranav K
Piotr Wosiek
Hao Kung
Filip W
Ajay Bhargav Baaskaran
Nate McMaster
Nate McMaster
Ryan Nowak
Doug Bunting
Doug Bunting
James Newton-King
Ryan Brandenburg
Stephen Halter
Javier Calvarro Nelson
Pavel Krymets
Wouter Huysentruit
Justin Kotalik
Chris Ross
Chris Ross (ASP.NET)
Gert Driesen
N. Taylor Mullen
Patrick Westerhoff
dotnet-maestro-bot
Steve Sanderson
Meir Blachman
Lukas Bickel
John Luo
MK
itminus
MikaelMengistu
David Fowler
David
Peter Blazejewicz
Turner Bass
BrennanConroy
Ben Adams
Günther Foidl
David J. Quiroga
George Drak
Luke Latham
Jo Ham
Andrei Amialchenia
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