* Always fully build Components.Server.csproj
* Use pre-built js files instead of building on the fly
* Use a sourcemap file for Debug. .gitignore sourcemap files
* Install nodejs on CodeCheck agents
Fixes https://github.com/aspnet/AspNetCore/issues/9402
VS 16.1 tooling does not support RazorConfigurations with no extensions
Working around this by treating Blazor templates as using MVC configuration
until we can resolve the issue in tooling
Workaround for https://github.com/aspnet/AspNetCore/issues/9119
* Chain coherent dependencies up through Extensions to EF Core packages
- should reduce incoherent PRs we get from `darc`
- react to AspNetCore-Tooling breaking changes
- use C# Preview version in Blazor integration tests
- update `EnsureOptions_ConfiguresDefaultParseOptions` test to match new C# version default
- react to new newline encoding behavior; thanx @ajaybhargavb!
- update product code and tests to use new GetItem API; thanx @NTaylorMullen!
- RazorProjectFileSystem breaking change
- update ref assemblies
- react to EF Core breaking changes
- react to EF Core method rename
- react to aspnet/EntityFrameworkCore@ccfc5edbc7
- react to aspnet/EntityFrameworkCore@6cb41531df breaking change
- disable new analyzer in `ScratchDatabaseFixture`
- skip `MvcTemplate_NoAuthImplAsync(...)` test for F#
- #8996
- exclude some runtime assemblies from crossgen; thanx @BrennanConroy!
- add direct references to Mvc in AzureAD samples
- unclear why the reference is no longer pulled in transitively
* Run `darc` to grab the latest
- CoreFx packages with version 4.6.0-preview4.19204.1 to ensure coherency
- core-setup packages with version 3.0.0-preview4-27604-05 to ensure coherency
- Extensions packages with verisn 3.0.0-preview4.19204.2 to ensure coherency
- EntityFrameworkCore packages with version 3.0.0-preview4.19204.7 from build 20190404.7
- AspNetCore-Tooling packages with version 3.0.0-preview4.19204.2 from build 20190404.2
* Move contents of Microsoft.AspNetCore.Components.Services namespace to Microsoft.AspNetCore.Components
* Rename Components to Blazor
* Make Blazor server-side part of the shared framework.
Fixes: #6887 and #6887 and #5624
Adds support for calling Blazor.start({...}) and passing in a
configuration object.
For now all you can configure is the SignalR HubConnectionBuilder. This
is a priority right now because we want to make configuring SignalR's
logging accessible.
* [MVC][Components] Prerendering + Robust reconnect
* Relayers prerendering support on a separate package on top of MVC and
components.
* Implements robust reconects with acknowledgements from the client.
* Improves interactive prerendering with the ability to reconnect to
prerendered components.
* Removes the need to register components statically when prerendering
them.
* Removes the need of using an element selector when prerendering an
interactive component.
* Updates the templates to use the new fallback routing pattern and
reenables the components test.
* Adds eslint to the Typescript project to help maintain a consistent
style.
* Adds logging to support better debugging based on the pattern used by
signalr.
* Fixes exception handling on the server to always report exceptions correctly to the client.
* Basic implementation of IComponentContext with IsConnected flag
* Update ref assembly code
* Begin infrastructure for prerendered E2E tests
* Actual E2E test for prerendered-to-interactive transition
* Make endpoint middleware explicit
This change makes the endpoint middleware explicit again, and updates
all of the templates.
The other change here is make UseEndpoints be the place where you
register endpoints. This is vital because it puts your code visually at
the point of the pipeline where it executes.
Lastly, I removed support for UseMvc with endpoint routing. This is
causing issues for some security features, and we're moving in the
direction of trying to make the middleware heavy implementation required
in 3.0. There are some issues we won't be able to fix in MVC if we can't
unambiguously know if UseMvc was used or the middleware.
This resolves the issue blocking use of component parameters from our
ref assemblies. Making properties public with private get is our
recommended guidance for wanting documentation to work in the IDE.
We also now need to manually generate the ref-assembly types for these
so they will show up for tooling with setters. I've logged an issue to
track whether we want to keep this long term, it seems like a suitable
workaround for now.
Fixes: #8609
Currently exceptions thrown during prerendering are simply logged. This
change uses the existing *unhandled exception* mechanism of the
renderer/circuit to throw these. The result is that the developer
exception page just works for prerendering.
* Improved selenium start and tear down
* Selenium is set up and torn down in an assembly fixture.
* Selenium is initialized lazily and in a non-blocking way.
* Selenium processes are tracked as part of the build and their pids
written to a file on disk for cleanup in the event of unexpected
termination of the test process.
* Browser fixture retries with linear backoff to create a remote
driver. Under heavy load (like when we are doing a simultaneous NPM
restore) the selenium server can become unresponsive so we retry
three times, with a longer comand timeout allowance each time up to
a max of 3 minutes.
* Moved test project setup to build time instead of runtime.
* Added target PrepareForTest to create the required files for testing
* The template creation folder.
* The template props file to use our built packages.
* The folder for the custom hive.
* Added assembly metadata attributes to find all the data we need to
run the tests.
* Path to the artifacts shipping packages folder.
* Path to the artifacts non-shipping packages folder.
* Path to the test templates creation folder.
* Path to use for the custom templating hive used in tests.
* Proper cleanup as part of the build
* Remove the test templates creation folder.
* Remove the test packages restore path.
* Recreate the test templates creation folder.
* Recreate the test packages restore path.
* Generated Directory.Build.Props and Directory.Build.Targets in the
test templates creation folder.
* Cleaned up potentially stale templatetestsprops.
* Improved test flows
* Initialization is done lazily and asynchronously.
* Selenium
* Browser fixture
* Template initialization.
* Flattened test flows to avoid assertions inside deep callstacks.
* All assertions happen at the test level with improved error messages.
* With the exception of the migrations assertions.
* Assertions contain information about which step failed, for what
project and what failure details.
* Broke down tests to perform individual steps instead of mixing build
and publish.
* Publish project.
* Build project. (Debug)
* Run built project.
* Run published project.
* Concentrated build logic into the Project class.
* Context between the different steps of a test is maintained in
this class.
* All operations that require coordination are performed within this
class.
* There is a lock for dotnet and a lock for nodejs. When building
SPAs we acquire the nodejs lock to correctly prevent multiple
runs of nodejs in parallel.
[ApiAuthorization template cleanups]
* Fix preview3 issues with breaking changes on Entity framework by
manually configuring the model in ApiAuthorizationDbContext.
* Add app.db to the project file when using local db.
* Fix linting errors on angular template.
* Fix react tests
* Add tests to cover new auth options in the SPA templates.
* Unify the Templating and Components testing infrastructure.
* Enable test project discovery in the components E2E tests.
* Enable selectively disabling Selenium tests through build properties.
* Removes a bunch of trivial usage of Blazor
... in names and comments where we don't specifically mean Blazor.
* Remove obsolete Startup from Components app
* Move UseBlazor into Blazor.Server
Moves UseBlazor and the related features in Blazor.Server - along with
some other general cleanup of misc shared files.
Now Components.Server has a much slimmer set of dependencies (MVC is
gone) and doesn't contain the "double startup" pattern that we
introduced (sorry).
We'll revisit UseBlazor and the dependencies there once the new
MapFallbackToFile support is available from static files.
* minor PR feedback
* Update reference assemblies
* fix broken test
* Make InputBase use EventCallback for ValueChanged
... so that the host component gets re-rendered automatically after each value change (like when binding to DOM elements).
* Improve E2E test code
... so that the host component gets re-rendered automatically after each value change (like when binding to DOM elements).
[Components] Prerrendering startup experience
* Introduces an IComponentPrerrenderer to handle Prerrendering
* MVC registers a basic static prerrrenderer.
* Components registers a more feature complete prerrender that will
handle reconnection to the original circuit after prerrendering in
the future to allow for prerrendered interactive components.
* Removes UseRazorComponents
* Removes the SPA fallback in favor of a catch all route in
Index.cshtml
* Moves the framework files to be served by the default StaticFiles
middleware in the pipeline by way of plugging specific providers
through options.
* Lifts UseSignalR(r => r.MapHub<ComponentHub>()) into startup and
replaces it with a shorthand for MapHub using endpoint routing.
* Adds extension methods to map components to selectors for a given
hub.
* Updates the razor component templates to include prerendering and use a razor page as the entry
point.
Changes:
* Make Visual Studio 2019 a prerequisite for building this repo
* Update .sln files
* Update Windows SDK to 17134
* Update developer docs
* Disable ANCM tests
* Update to .NET Core SDK 3.0 Preview 2
* Use Microsoft.NET.Sdk.Razor as a package consistently accross the repo
* React to changes in metadata from Microsoft.NETCore.App
* React to changes in .NET Core SDK
* Attempt to workaround CodeCheck.ps1 failure which doesn't repro locally or on different agents. Possibly due to differences in the version of the PowerShell task?
* Remove dead YML file
* Rename usages of win7-{x64,x86} to win-{x64,x86}
* Update KoreBuild to 3.0.0-build-20190219.1
* In Blazor hosted template, only UseBlazorDebugging in development environment. Fixes#7275
* Enable HTTPS in the Razor Components template. Fixes#6928
* Reduce Razor Components template to one project. Fixes#6883
* Minor phrasing tweak
* In Razor Components template, change .cshtml to .razor, except _ViewImports.cshtml
* Put back LangVersion
* Update RazorComponentsTemplateTest
The changes here make event dispatching (including bind) more
user-friendly by avoiding the need for manual calls to StateHasChnaged.
We also introduce a new type `EventCallback` (and `EventCallback<T>`).
This is a new primitive that is like a super-powered version of a
delegate. When writing a component that accepts delegates as parameters,
consider using `EventCallback` for the following reasons:
- Allows consumer to pass a variety of different delegate signatures
- Does proper event dispatching and error handling
Using `EventCallback` will eliminate most of the remaining cases where a
manual `StateHasChanged` is required when components are passing content
and delegates to each other.
`EventCallback` is inherently async for the reason that this is really
the only way to provide correct error handling.
-----
The fix for this will be two-phase by first creating a set of APIs that
can be targeted by the compiler that has the desired behaviour and then
updating the compiler to target this new infrastructure.
When a `<Reference>` is named `*.Sources`, set PrivateAssets=All (exclude from generated nuspec) and IncludeAssets=ContentFiles (only consume content files, not .dll's)
* Improve Components error handling
* Change event handlers IHandleEvent, IHandleAfterEvent to be async.
* Return faulted tasks to Renderer instead of handling exceptions in ComponentBase
* Use ILogger in RemoteRenderer, and log to console in WebAssemblyRenderer
* Cleaning up touched files
Fixes https://github.com/aspnet/AspNetCore/issues/4964
Changes:
* Add support for a property, `IsAspNetCoreApp`, in the .csproj file of assemblies which are part of the shared framework.
* Remove unused dependencies
* Remove reference which have become part of 'netcoreapp3.0'
Add new command line parameters for working with the project:
* `-NoBuild`, `-NoRestore` - these already existed, but users found it hard to discover this powershell syntax: '-build:$false'
* `-Arch`/`--arch` - set the target CPU architecture to build. Defaults to x64
* `--os-name` - on non-Windows builds, manually specify if the build should target Alpine. generic Linux, or MacOS
* Rename flags used to build specific project types. The pattern now is `--build-$(group)` or `--no-build-$(group)` (In PowerShell its `-Build$(Group)` or `-NoBuild$(Group). Example: -NoBuildJava
Changes to build definitions:
* Update the ci build definition to build all supported architectures
* Support publishing multiple artifacts per job
Other changes:
* `-NoBuild` implies `-NoRestore`
* Add new properties, `TargetArchitecture`, `TargetOsName`, and `TargetRuntimeIdentifier`
* Replace usages of `SharedFxRid` with these new properties
* To make `--no-build-nodejs` actually work, replaced Components.Browser.JS.csproj with Components.Browser.JS.npmproj
* Fix errors when building for win-arm on a clean machine
* Fix a few other project errors, like using the wrong syntax for DefaultItemExcludes, or using the wrong Platform value for x86
Changes:
* Remove obsolete targets which are unnecessary now that this repo no longer builds git submodules in a separate build process
* Remove the need for static analysis of 'ArtifactInfo' items
* Simplify how the code signing task is configured
* Remove unused repo tasks
* Remove duplicate lists of external dependencies and packages to be produced
* Remove obsolete build definition
* Remove obsolete build script parameters
* Add VisualStudioSetupOutputPath
* Remove Blazor.LanguageServices
The text-view-listener was the only thing here and it's not needed
anymore now that these features are build into our main VS payload.
We won't have any more code to put in this project because it's this
VSIX is pretty temporary.
* Remove reference to ProjectSystem
We don't need this reference, and it's got some breaking changes between
15 and 16 - rahter then mess with nuget sources for vs16 packages, I'm
just going to drop the dependency
* Remove unused cruft
* Target net472
* Add Blazor VSIX to build
* Add Extension to .sln
* Use AsyncPackage
* Update and streamline references
* Update manifest for 16.0
* Pack Templates before building VSIX
* Fix version of templates
* Updates the IComponent interface to rename Init into Configure
* Updates the IComponent interface to change SetParameters for
SetParametersAsync and make it return a Task that represents when the
component is done applying the parameters and potentially triggering
one or more renders.
* Updates ComponentBase SetParametersAsync to ensure that OnInit(Async)
runs before OnParametersSet(Async).
* Introduces ParameterCollection.FromDictionary to generate a parameter
collection from a dictionary of key value pairs.
* Introduces RenderComponentAsync on HtmlRenderer to support
prerrendering of async components.
* Introduces RenderRootComponentAsync on the renderer to allow for
asynchronous prerrendering of the root component.
* Add Components packages to shared fx
* Add Microsoft.AspNetCore.Components \ Microsoft.AspNetCore.Components.Browser to shared fx
* Update build to use Microsoft.InteropJS package produced from Extensions repo
* Remove some package references from components template
Fixes https://github.com/aspnet/AspNetCore/issues/6442
* 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.
Update the build scripts to support building subfolders or subgroups of projects
* Add build scripts for ci
* Remove obsolete scripts
* Add flags like --test and --pack to control running just test or packaging
* Add flags like --managed and --native to control building sub-types of projects
* Remove KoreBuild bootstrapper flags
* Update to extensions 3.0.0-preview.18619.1 (needed to get a fix for aspnet/Extensions#815 to make this change work on MSBuild.exe)
This simplifies the way that we publish files to our network drop share.
Changes:
* Instead of explicitly listing every file that needs to publish, use directories to classify packages and artifacts into different categories.
* Add documentation for the expected layout of artifacts/
* Remove the need for static analysis to determine which packages go to which project
* Add the MSBuild property "IsProductPackage" to .csproj files which ship as a package to NuGet.org.
As a result of removing Razor's VS projects and upgrading all projects to netcoreapp3.0, we no longer need dependency variable for .NET Core 1.x and 2.x and Visual Studio packages.
Changes:
* Remove 'StandardTestTfm'
* Remove variables for .NET Core 1.0, 1.1, 2.0, 2.1, and 2.2
* Remove VSIX variables
* Stop generating 'branding.props' - this hasn't been used in a while and is no longer needed