* Updates the router component to scan for components within assemblies.
* Parses the templates on `[Route]` in component instances and builds a
route table that maps paths to components.
* Uses the route table to map paths to components.
* 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
Adds the @page directive and support for specifying routes in components
at compile time.
For now the route is required and must begin with a leading /.
* 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.
This removes a limitation that prevented callers from passing
attributes to a component that aren't backed by properties.
The majority of the complication here is required to deal with the more
sophisticated way that HTML attributes are represented in the Razor IR.
This builds upon existing support for UIEventHandler-typed component
properties and applies the same principle to any delegate type.
We try to help by generating the LSH of the lambda `=>` allowing you to
write `OnClick="Foo()"` rather than `OnClick="(e) => Foo()"`. You can of
course use @ as an escape.
The only rough edge here is that if the parameter names aren't memorable
for the delgate type, it's not super helpful.
This reverts commit b448a5d096a27de5c8e700e43a264673de16b632.
This is because CI is currently unable to complete the signing process
so we can't upload that particular build.
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.
* Remove unnecessary <OutputType>Exe</OutputType> from templates
* Rename BlazorHosted.* projects to BlazorHosted.CSharp.(Client|Server)
* Add empty BlazorHosted.CSharp.Shared, referenced from the two other BlazorHosted.CSharp.* projects
* Have BlazorHosted.CSharp.Client fetch data from BlazorHosted.CSharp.Server
* Update templates to Blazor 0.0.5-preview1-10037
* Make date handling consistent across the templates
* Enable response compression in "hosted" template
* Enable response compression in dev server
* Simplify template app code using new namespace arrangement
* Fix project name in hosted template
MiniJSON is very small but doesn't deal with strongly-typed
deserialization by default (we can add it, but that's less
battle-tested). Also it has to allocate extra IDictionary versions of
everything before we map it to specific .NET types.
Also tried LitJSON, but has some correctness issues, e.g.,
https://github.com/LitJSON/litjson/issues/43
Also tried Json.NET but it's > 600KB
Steve Sanderson
Javier Calvarro Nelson
Pranav K
Ryan Nowak
Ryan Nowak
Florian Dohrendorf
forest93
Daniel Roth
Alex Gavrilov