* Stop referencing BlazorBuildToolsExe in .Browser.JS
* Have Components projects always reference .Blazor.Mono as a package, not from source
* Finish decoupling of .Browser.JS from Blazor.BuildTools
* Fix reference resolver unit test to find Mono BCL in .Blazor.Mono package
* Remove typo
* Have .Browser.JS consume jsinterop only via an NPM package reference
* Reference JSInterop .NET libraries only via NuGet package references, not directly from source
* Update dependency resolver unit test
* Update package name in package-lock.json
* When bundling jsinterop DLL into Build package, don't re-sign it (treat it as external)
* Rename "mono" project to Microsoft.AspNetCore.Blazor.Mono
* Include binary content in Microsoft.AspNetCore.Blazor.Mono
* Reference Mono binaries in Blazor.Mono project instead of Components.Build
When only Microsoft.AspNetCore.App is referenced, the project will no longer have MSBuild imports from the Microsoft.Extensions.Configuration.UserSecrets package, which takes care of generating the UserSecretsIdAttribute. This ensures the attribute is still generated in default project templates without needing a new package ref to Config.UserSecrets.
* Rename Microsoft.AspNetCore.Blazor dir to .Components
* Rename Microsoft.AspNetCore.Blazor.Browser dir to .Components.Browser
* Rename Microsoft.AspNetCore.Blazor.Browser.JS dir to .Components.Browser.JS
* Rename Microsoft.AspNetCore.Blazor.TagHelperWorkaround dir to .Components.TagHelperWorkaround
* Unbreak signing
* Rename Microsoft.AspNetCore.Blazor.Analyzers dir to .Components.Analyzers
* Rename Microsoft.AspNetCore.Blazor.Server dir to .Components.Server
* Rename Microsoft.AspNetCore.Blazor.Razor.Extensions dir to .Components.Razor.Extensions
* Rename Microsoft.AspNetCore.Blazor.Build dir to .Components.Build
* Rename Microsoft.AspNetCore.Blazor.Test dir to .Components.test
* Rename Microsoft.AspNetCore.Blazor.Server.Test dir to .Components.Server.Test
* Rename Microsoft.AspNetCore.Blazor.Razor.Extensions.Test dir to .Components.Razor.Extensions.Test
* Rename Microsoft.AspNetCore.Blazor.Analyzers.Test dir to .Components.Analyzers.Test
* Rename Microsoft.AspNetCore.Blazor.Browser.Test dir to .Components.Browser.Test
* Rename Microsoft.AspNetCore.Blazor.Build.Test dir to .Components.Build.Test
* Rename Microsoft.AspNetCore.Blazor.E2ETest dir to .Components.E2ETest
* Fix typo
* Unbreak VSIX build
* Fix .Build unit tests
* Move Blazor benchmarks into blazor subdir
* Rename .Blazor.Performance dir to .Components.Performance
* Move some samples within .sln
* Move StandaloneApp sample to blazor subdir
* Move MonoSanity sample to blazor subdir
* Move HostedInAspNet sample to blazor subdir
* Update paths to samples
* Move .BuildTools and .Cli sources to blazor subdir
* Move tooling to blazor subdir
* Move templates to blazor subdir
* Restore Directory.Build.props behaviors in blazor\src
* Move mono to blazor subdir
* Update folder structure in .sln
* Fix VSIX
* Empty commit to reawaken CI
* Fix manual standalone app startup
This should unblock the consumption of the latest .NET Core SDK, which includes breaking changes in MSBuild. We don't _really_ need the MSBuild APIs which were broken because ProdCon v1 is dead. This removes the unused ProdCon v1 tasks and targets.
This change introduces a service facade for creating the application
model, running conventions, validating the result, and flattening the
model.
This is used in the ControllerActionDescriptorProvider and provides the
existing functionality for now. The ControllerActionDescriptorProvider
will process the results and turn each 'flattened' model into a single
action descriptor.
The next change will introduce another consumer of this service, that
turns the 'flattened' model into an EndpointModel so that it can be
exposed via Endpoint Routing's convention system.
---
The main considerations here:
The flattening semantics of application model are pretty complicated :(
The validation that CADP does is actually pretty in depth and might be
really low value... Errors with writing route templates do happen, and
those will be caught by the routing system eventually.... Errors with
duplicate route names are similar... Errors with 'mixed' attribute and
conventional routing are not at all common. I don't think I've ever seen
an issue get filed about this. I did the work to port all of this stuff
forward but I'm not totally sure it's valuable - however, I don't really
want to make an argument for its removal. These are just some random
thoughts to keep in mind if you're reviewing this 👍
* Update Extensions to 3.0.0-preview.18569.14
* Update EFCore to 3.0.0-preview.18569.2
* Update corefx to preview.18566.8
* Update core-setup to preview-27117-01
Changes:
* Upgrade dependencies and build tools
* Change TFM on Microsoft.AspNetCore.Routing packages to netcoreapp3.0
* Remove .NET Framework tests
* Remove the IL_EMIT conditional compilation because this assembly only targets .NET Core now.
Changes:
* Upgrade dependencies and build tools
* Change TFM on Microsoft.AspNetCore.* packages to netcoreapp3.0
* Remove .NET Framework tests
* Disable Owin interop tests. They need to be completely refactored
This generates additional metadata for the .NET Core SDK to resolve conflicts between Microsoft.AspNetCore.App and PackageReferences which contain the same assemblies.
This changes the way Microsoft.AspNetCore.App works to follow patterns set by Microsoft.NETCore.App. Instead of being a metapackage with dozens of dependencies, this package has no dependencies. It uses RID-splitting to deliver standalone assets for self-contained deployments.
Changes:
* Implements RID-split packages for Microsoft.AspNetCore.App.
* Update shared fx deps.json generation to only include entries for the RID-specific metapackages
* Include platform-specific packages in publish output
* Remove all nuspec dependencies of Microsoft.AspNetCore.App and collect all references into the package.
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
- #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
Chris R
Ryan Brandenburg
dotnet-bot
Justin Kotalik
Stephen Halter
Steve Sanderson
Ryan Nowak
Nate McMaster
Chris Ross (ASP.NET)
Pranav K
Nate McMaster
BrennanConroy
Kirill Osenkov
Javier Calvarro Nelson
Jacques Eloff
Jacques Eloff
Pavel Krymets
Luke Latham
Doug Bunting
Ben Adams
Alexej Timonin
David Fowler
Ajay Bhargav Baaskaran
Hao Kung
=
John Luo
Kévin Chalet
Eilon Lipton
Hisham Bin Ateya
Daniel Roth
James Newton-King
Gert Driesen
David Blankenbush
Ben McCallum
Doug Bunting
Henk Mollema
Adrian Wright
Jeremy Hutchinson
Suchiman
N. Taylor Mullen
Alexander Shabunevich
Liam Dawson
Mike Lorbetske
Mike Lorbetske
Piotr Wosiek
Filip W
Ajay Bhargav Baaskaran
Wouter Huysentruit
Patrick Westerhoff
dotnet-maestro-bot
Meir Blachman
Lukas Bickel
MK
itminus
MikaelMengistu
David
Peter Blazejewicz
Turner Bass
Günther Foidl
David J. Quiroga
George Drak
Jo Ham
Andrei Amialchenia
Brian Chavez
Ryan Nowak
Simon Cropp
Unai Zorrilla
Roma Marusyk
andrewslavin
Tomasz Jaskula
KristianJakubik
melnikov77
Mike Harder
tiago-soczek
Daniel A. White
Rick Anderson