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

[SteveSandersonMS]

Currently the build/publishing process doesn't differentiate between WebAssembly and server-side Blazor apps, and hence it outputs mono.wasm/mono.asm.js and the _bin directory (containing client-downloadable .NET assemblies) in both cases.

You do want to publish those files for WebAssembly apps, but you don't for server-side only ones (partly because it's pointless extra stuff to publish, and partly because you might actively not want clients to be able to download the Blazor app assemblies, since you only intend to use them on the server).

Proposal

1. In the Blazor client project, add an MSBuild property like <OutputWebAssemblyFiles>true</OutputWebAssemblyFiles>. This will be present by default in our WebAssembly project templates, but not the server-side one. Then we change the build process so that, if this flag is not present, it does not emit the _bin/asmjs/wasm directories.
   • Obviously this is a breaking change, but it's pretty easy for people to add this to their existing apps.
   • I think it should be opt-in like this, not opt-out, because it gives people a better chance of recognizing that they even have a choice.
   • Having this flag also slightly simplifies the server-side template, because it no longer has to explicitly opt out from running the linker. The linker wouldn't be run anyway if we weren't outputting the WebAssembly files.
2. We can also use the OutputWebAssemblyFiles flag to know whether to include a list of .NET assemblies in _framework/blazor.boot.json, hence also solving Entity Framework 6 - System.IO.FileNotFoundException in DatabaseFirst approach #1233.

@danroth27 / @rynowak - thoughts on this design? Any other way you'd prefer it to be configured?

The main way people could still get this wrong is by adding a new Blazor client project to an existing solution to use it as a server-executed app, but forgetting to remove the <OutputWebAssemblyFiles> flag. Not sure how big of an issue to consider that.

[danroth27]

I think it should be opt-in like this, not opt-out, because it gives people a better chance of recognizing that they even have a choice.

Why do we want folks to recognize that they have a choice? Having this be opt in seems to contradict our principle that we are optimizing for the client.

[SteveSandersonMS]

Why do we want folks to recognize that they have a choice?

Only because there's a security aspect. If by default we're letting clients download .NET .dll files, that could come as a surprise for people who think of their app as running server-side only.

[manuelbl]

Server-side Blazor promises to be more secure, more proprietary than any client-side SPAs. If so, .NET assemblies must not be published and prevented from being downloaded. For certain third-party libraries, the license might forbid to make the .NET assembly publicly available.

Furthermore, server-side Blazor app should not publish the list of assemblies (see #5564). The file blazor.bootl.json most likely is not needed at all.

Even for client-side Blazor apps, only the assemblies needed on the client-side should be published.

[SteveSandersonMS]

Done in #6562

The design is simply to have different "build" packages depending on whether you're targeting WebAssembly or not. Microsoft.AspNetCore.Blazor.Build publishes the dlls to client-downloadable locations, whereas Microsoft.AspNetCore.Components.Build does not.