* Only use async marshalling to renderer sync context when necessary
Note that the lifecycle methods already take care of capturing the correct sync context, so continuations will already be serialized.
Avoiding an extra layer of asynchrony keeps the semantics of rendering closer to the WebAssembly cases, and will fix a range of intermittent errors in the wild.
* Add E2E test of triggering rendering from outside the sync context
* Actually throw if attempting to render from incorrect sync context
* Add "Dispatch" API
* Handle dispatch within dispatch. Also test Dispatch on WebAssembly.
* Avoid heap allocation
* Simplify E2E test
* Replace Dispatch() with Invoke() and InvokeAsync()
* Add E2E test to validate async execution order
* Clean up
* Replace UseServerSideBlazor with UseRazorComponents, which doesn't require Blazor build artifacts
* Make UseRazorComponents serve blazor.server.js from embedded resource
... so we don't need a build step to put it on disk somewhere.
* Fix TestServer
* Update ComponentsApp not to use Blazor build targets
* Update ComponentsApp.App sample to use new build package
* Update string constant in test
* Rename blazor.*.js to components.*.js
* Ensure correct build order
* Update nav menu title in Components sample app
* Fix remaining paths
* Switch ComponentsApp.App to use Sdk="Microsoft.NET.Sdk.Razor"
* Update mono.cecil version
* CR: Replace FrameworkFilesProvider with EmbeddedFileProvider
* CR: Use ManifestEmbeddedFileProvider
* Move Components.Build to blazor/src/. No content changes yet.
* Rename Components.Build to Blazor.Build and update file paths
* Move Components.Build.Test files. No content changes yet.
* Update contents in Blazor.Test
* Fix names of props/targets files
* Add minimal Components.Build package that just imports Razor targets and analyzer
* Make Blazor.Build depend on Components.Build and get Razor compilation targets from there
* Fix version of reference from .Blazor.Build to .Components.Build
* Fix signing error on local builds
* Update artifacts.props
* Auto-install local copy of selenium-standalone on build
* Automatically start/stop selenium-standalone when running E2E tests
* Update after rebase
* Exclude node_modules from E2ETests project
* Avoid deadlocks
* Include E2E tests when running all tests in src/Components
* Be more forgiving about waiting for selenium-server to be ready
* Update usage of shared source file
This wasn't properly forwarding the base path to the configuration.
Basically nothing was setting RemainingArguments. We have a test project
that sets the base path, but it was never used when debugging locally.
I also cleaned this up a bit and changed it to use dotnet exec. This
allow you to debug the CLI and related server pipeline, but has the
tradeoff of not rebuilding.
Steve Sanderson
Nate McMaster
Pranav K
Ryan Nowak
Ajay Bhargav Baaskaran
Javier Calvarro Nelson