* Add build command for generating the new boot JSON file
* Remove build command for generating index.html
* Update build targets to generate blazor.boot.json
* Change SPA fallback routing to look for index.html in regular wwwroot. Will need to update setup for published apps later.
* Stop autorebuild when index.html changes, since we no longer 'build' that file
* Update Boot.WebAssembly.ts logic to use boot JSON info on startup
* Restore support for loading CSS/JS from Blazor library projects
* Use new startup script tag in all samples and templates
* Fix MonoSanity sample - it must now be an exe because we use that as the trigger to generate the boot json (not the presence of index.html any more)
* Fix SPA fallback routing for published apps
Because in a previous commit, I changed it to look for index.html inside "wwwroot" instead of "dist" (because we no longer build it). But "wwwroot" doesn't exist for published apps, because static file servers wouldn't understand it.
* CR: Fix path normalization
- Prepare for building multiple entrypoint variants of the .js library
- Use async interop more consistently for rendering and event handling
- Add binary serializer for RenderBatch with tests
Updates ASP.NET package versions to 2.1
Tweaks TFMs
- libraries = netstandard2.0
- exes/apps/tools = netcoreapp2.1
- unit tests = netcoreapp2.0
- e2e tests = netcoreapp2.1 (dependency on apps)
The exception to this is the Browser.JS project which depends on our
tool for its build. however this project just builds the js code so its
TFM doesn't really matter.
The root cause here was that we weren't setting the language version in
MSBuild, which is only for the command line version.
(cherry picked from commit 319e31f71a150e9b0d91e724f0e358390caec4c2)
This change should hopefully end the MSBuild craziness that happens when
you add a file to the project using the VS Add Item dialog.
VS apparently has a behavior that intentionally tries to make sure the
added file is only included in a single itemgroup. So when Blazor
defines an itemgroup at the top level of scope with the same members as
Content - VS does some gymnastics to prevent it working.
The workaround is to defer the initialization of our itemgroup.
* Before refactoring ParameterCollection assignment logic, add more test coverage
* Begin caching parameter assignment info
* Factor out some reflection code to a reusable location
* Use IPropertySetter to avoid all per-property-assignment reflection
* More error cases and tests for parameter assignment
* Enable binding to nonpublic properties
* Add analyzer to warn and provide fix for public component parameters
* Unit test for analyzer
* Component tag helper now includes private properties if they have [Parameter]
* CR feedback: Remove garbage from csproj
* CR feedback: Rename .Build.Analyzers to .Analyzers
* CR feedback: Move BlazorApi.cs to shared; use it from Analyzers test
* Fix incorrect test name
* Make as many parameters private as possible. Replace ILayoutComponent with BlazorLayoutComponent.
* In component tag helper discovery, consider private members too
* Reduce the work in component parameter discovery by not inspecting the BlazorComponent base class (or System.Object)
By making Razor.Design a transitive dependency of Blazor.Build we can
avoid the need for users to care which version of Razor we depend upon,
and take it out of the templates.
* On build, drop <BlazorPackageContentFiles> items into dist\_content\(PackageName)\
* Add <script> and <link> tags to generated index.html
* Add testapp coverage of external content package. Still need to add E2E tests that uses it.
* Add missing unit test update
* Add example of packaging an entire Blazor component including CSS and images
* Add E2E test for component from NuGet package
* Switch the tasks used to generate the blazor output to be MSBuild based.
* Package the optimized mono runtime and the BCL inside a nuget package.
* Add opt-in support for linking the application on build.
* Make the whole build process incremental.
Implements Component code generation and tooling support end to end
udditionally adds some default `@addTagHelper` directives to make
programming in Blazor a little nicer.
Components are discovered as Tag Helpers using Razor's extensibility
during the build/IDE process. This drives the code generation during
build and lights up a bunch of editor features.
Add
This is a working (all tests passing) implementation of the two-phase
compilation system we will need for component discovery.
This builds on top of work we've doing in Razor, including the Razor
SDK, MSBuild tasks, and CLI/server.
This currently *does* discovery components during the build process, but
it doesn't use that data for anything yet.
It works like this:
1. Generate class declarations (structure only, no method bodies)
2. Compile a 'temp' assembly using the .cs files and output of 1.
3. Do component discovery using the 'temp' assembly
4. Generate class definitions (including method bodies)
5. Compile the 'real' assembly using the .cs files and output of 4.
Adds a little more use of Razor extensibility.
Razor is a plugin model, so we can't be the 'first mover' for initiating
compilation in the build tools and IDE.
Reorganizes tests and fills out more reusable test infrastructure for
Razor-driven testing.
Adds tests for declaration-only configuration.
Steve Sanderson
Ryan Nowak
Anthony Chu
Nikolei, Stefan
Marcus Bowyer
Ryan Nowak
Javier Calvarro Nelson
Pranav K