Make Razor Components apps not use Blazor build #6562

SteveSandersonMS · 2019-01-10T10:59:52Z

Previously for Razor Components, we ran the entire Blazor build process which includes:

Enabling the components Razor compiler
Putting the .NET assemblies in a client-downloadable location (including linking them by default)
Tracing the dependency graph and generating a boot.json file
Writing a blazor.config.json file to the server project's bin dir to specify the client app location
Copying any library-embedded resources into bin/dist
Copying the Mono WebAssembly binaries into bin/dist
A similar set of complex modifications to the publishing process (e.g., copying the client app dist files into the server project's bin dir)

The considerable majority of this is irrelevant for Razor Components apps, and is somewhat harmful because it not only makes the build slower and have more potential failure points, but also has runtime drawbacks such as #5589. Once #6538 is merged, we have a way to include only the "enable the components Razor compiler" part of the above and none of the rest.

This PR builds on #6538, eliminating the remaining runtime dependencies on Blazor build artifacts:

We no longer require the blazor.config.json file, because we no longer try to load any static assets from the client app location (we serve static content directly from the server project)
We no longer need to load blazor.server.js from the client app project, because it's now served directly from an embedded resource in .Components.Server middleware
We no longer require there to be a boot.json

This PR also cleans up some naming, such as renaming UseServerSideBlazor to UseRazorComponents, renaming blazor.server.js to components.server.js, and a few others.

The net result is that the Razor Components template can be extremely simple. Plus its build process is trivial, and we don't need any custom publishing steps. And there's no further technical requirement for it to be two separate projects - one would work just the same.

Caveat: This PR also has the side-effect that the Razor Components template will no longer support library-embedded resources or auto-rebuild by default, because the implementations for those are in the Blazor-specific packages. We can add these features back soon. This is tracked in #6442.

javiercn · 2019-01-10T11:08:28Z

src/Components/samples/ComponentsApp.App/ComponentsApp.App.csproj

-    </PropertyGroup>
+  <PropertyGroup>
+    <TargetFramework>netstandard2.0</TargetFramework>
+    <OutputType>Library</OutputType>


Is this needed?

Great point. It was needed only because the SDK was set to Microsoft.NET.Sdk.Web, which it shouldn't have been. I've changed the SDK to Microsoft.NET.Sdk.Razor and now we no longer need to override OutputType.

javiercn · 2019-01-10T11:13:02Z

src/Components/samples/ComponentsApp.Server/Startup.cs

-            // Use component registrations and static files from the client startup.
-            app.UseServerSideBlazor<App.Startup>();
+            app.UseStaticFiles();
+            app.UseRazorComponents<App.Startup>();


SteveSandersonMS · 2019-01-10T11:15:36Z

...icrosoft.AspNetCore.Components.Server/Builder/RazorComponentsApplicationBuilderExtensions.cs

+        /// <param name="builder">The <see cref="IApplicationBuilder"/>.</param>
+        /// <typeparam name="TStartup">A components app startup type.</typeparam>
+        /// <returns>The <see cref="IApplicationBuilder"/>.</returns>
+        public static IApplicationBuilder UseRazorComponents<TStartup>(


Technically we don't need the TStartup at all. I've left it here for symmetry with AddRazorComponents and in case we want to reserve the right to use that info in the future.

I'm totally open to changing this though.

Good to know. I think we should leave it as-is until we resolve all of the dependencies and tweaks needed to ship preview2.

javiercn · 2019-01-10T11:23:46Z

...icrosoft.AspNetCore.Components.Server/Builder/RazorComponentsApplicationBuilderExtensions.cs

+            // add SignalR and BlazorHub automatically.
+            if (options.UseSignalRWithBlazorHub)
+            {
+                builder.UseSignalR(route => route.MapHub<BlazorHub>(BlazorHub.DefaultPath));


does this need to be renamed to components?

Yeah, eventually. There are lots of remaining bits of renaming-cleanup like that, but I'm not trying to get all of them done before Preview 2. I'm only focused on the ones that are really in developers' faces in default scenarios, which this isn't.

javiercn · 2019-01-10T11:26:03Z

...icrosoft.AspNetCore.Components.Server/Builder/RazorComponentsApplicationBuilderExtensions.cs

+            builder.UseSpa(spa => { });
+
+            return builder;
+        }


This got me thinking.
If we somehow change the way we distribute /_framework files

The core of this method would be
builder.UseSignalR();
builder.UseSpa();

I'm wondering what your thoughts are on having something like this directly on the template.

builder.UseSignalR(r => r.MapComponentsHub());
builder.UseSpa(spa =>{ });

compared to
app.UseRazorComponents()

The reason for it being that it's more straightforward what's going on in the pipeline and its easier to manipulate, for example to add Azure SignalR (it composes better).

Thoughts?

If we somehow change the way we distribute /_framework files

Yep, we would need to do that. I'd be keen not to have components.server.js as a physical file in the project, because that gets into difficulty with versioning mismatches and people being confused into thinking it's a good idea to edit the contents or trying to bundle it with their own files.

The mechanism here of serving it from middleware in UseRazorComponents is preferable I think, but we can review the factoring as we go on. I'm totally open to making UseRazorComponents just be shorthand for a collection of lower-level middlewares you can add manually if you prefer.

. I'd be keen not to have components.server.js as a physical file in the project,

Also servicing.

rynowak · 2019-01-10T19:24:39Z

src/Components/src/Microsoft.AspNetCore.Components.Server/Builder/FrameworkFilesProvider.cs

+
+namespace Microsoft.AspNetCore.Builder
+{
+    internal class FrameworkFilesProvider : IFileProvider


A simpler way to do this would be to just use the embedded file provider no? If this is a temporary workaround for some stuff, I'm fine with it for now.

You're right. I've updated the code to remove FrameworkFilesProvider and use EmbeddedFileProvider.

Previously I was trying to unify how the components.server.js file and the blazor.boot.json file were served. But since blazor.boot.json is temporary it doesn't make sense to orient the design around that.

If this is a temporary workaround for some stuff

Serving a stub file for blazor.boot.json is a temporary workaround, but serving components.server.js from an embedded resource will hopefully remain.

…quire Blazor build artifacts

... so we don't need a build step to put it on disk somewhere.

javiercn · 2019-01-11T11:18:10Z

...icrosoft.AspNetCore.Components.Server/Builder/RazorComponentsApplicationBuilderExtensions.cs

+        {
+            builder.UseStaticFiles(new StaticFileOptions
+            {
+                FileProvider = new EmbeddedFileProvider(


I recommend using the ManifestEmbeddedFileProvider instead.
This one has some limitations and is more hacky than the ManifestEmbeddedFileProvider we use in the identity UI and other libraries, so it would be better if we just use the same all over the place.

SteveSandersonMS added this to the 3.0.0-preview2 milestone Jan 10, 2019

SteveSandersonMS requested review from rynowak and javiercn January 10, 2019 10:59

javiercn reviewed Jan 10, 2019

View reviewed changes

SteveSandersonMS commented Jan 10, 2019

View reviewed changes

SteveSandersonMS mentioned this pull request Jan 10, 2019

Finalize Razor Components template for preview 2 #6442

Closed

5 tasks

javiercn reviewed Jan 10, 2019

View reviewed changes

SteveSandersonMS force-pushed the stevesa/make-razor-components-apps-not-require-blazor-build branch from aeef043 to 910d63c Compare January 10, 2019 11:45

SteveSandersonMS changed the base branch from stevesa/rename-components-build-to-blazor-build to master January 10, 2019 11:45

rynowak reviewed Jan 10, 2019

View reviewed changes

rynowak approved these changes Jan 10, 2019

View reviewed changes

SteveSandersonMS mentioned this pull request Jan 11, 2019

Factor WebAssembly debugging infrastructure out of Microsoft.AspNetCore.Components.Server #6519

Merged

SteveSandersonMS added 13 commits January 11, 2019 10:31

Replace UseServerSideBlazor with UseRazorComponents, which doesn't re…

9a13ef2

…quire Blazor build artifacts

Make UseRazorComponents serve blazor.server.js from embedded resource

f9350f4

... so we don't need a build step to put it on disk somewhere.

Fix TestServer

ebdb966

Update ComponentsApp not to use Blazor build targets

1599a65

Update ComponentsApp.App sample to use new build package

0c012ef

Update string constant in test

5f11311

Rename blazor.*.js to components.*.js

30dfd71

Ensure correct build order

c8763c3

Update nav menu title in Components sample app

479d293

Fix remaining paths

39a6291

Switch ComponentsApp.App to use Sdk="Microsoft.NET.Sdk.Razor"

1d9ccce

Update mono.cecil version

80ac9fc

CR: Replace FrameworkFilesProvider with EmbeddedFileProvider

9b650ac

SteveSandersonMS force-pushed the stevesa/make-razor-components-apps-not-require-blazor-build branch from 910d63c to 9b650ac Compare January 11, 2019 10:56

javiercn reviewed Jan 11, 2019

View reviewed changes

CR: Use ManifestEmbeddedFileProvider

b82d3a1

SteveSandersonMS merged commit 70cdf11 into master Jan 11, 2019

SteveSandersonMS deleted the stevesa/make-razor-components-apps-not-require-blazor-build branch January 11, 2019 16:14

This was referenced Jan 11, 2019

Publishing for Razor Components #4055

Closed

Avoid publishing _bin/asmjs/wasm directories for server-side only apps #5589

Closed

This was referenced May 9, 2019

Blazor Javascript Files dotnet/AspNetCore.Docs#12358

Closed

Update source of the blazor.server.js script dotnet/AspNetCore.Docs#12374

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Make Razor Components apps not use Blazor build #6562

Make Razor Components apps not use Blazor build #6562

Uh oh!

SteveSandersonMS commented Jan 10, 2019 •

edited

Loading

Uh oh!

javiercn Jan 10, 2019

Uh oh!

SteveSandersonMS Jan 10, 2019

Uh oh!

rynowak Jan 10, 2019

Uh oh!

javiercn Jan 10, 2019

Uh oh!

SteveSandersonMS Jan 10, 2019

Uh oh!

rynowak Jan 10, 2019

Uh oh!

javiercn Jan 10, 2019

Uh oh!

SteveSandersonMS Jan 10, 2019

Uh oh!

javiercn Jan 10, 2019

Uh oh!

SteveSandersonMS Jan 10, 2019

Uh oh!

rynowak Jan 10, 2019

Uh oh!

rynowak Jan 10, 2019

Uh oh!

SteveSandersonMS Jan 11, 2019

Uh oh!

javiercn Jan 11, 2019

Uh oh!

SteveSandersonMS Jan 11, 2019

Uh oh!

Uh oh!

Make Razor Components apps not use Blazor build #6562

Make Razor Components apps not use Blazor build #6562

Uh oh!

Conversation

SteveSandersonMS commented Jan 10, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

SteveSandersonMS commented Jan 10, 2019 •

edited

Loading