blazor.web.js is no longer delivered in a Library project

[gemelo-Peer]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

Background
I have a larger project that uses ASP.NET Blazor at a crucial point. The entire Blazor application is outsourced to a separate project, which was until now a library with the SDK ‘Microsoft.NET.Sdk.Razor’ (Library). The library has a host class with Start() and Stop() methods that set up and start or stop the web application. It should be possible to use it completely independently in other projects (e.g. WPF, server service), especially without the consumers of the library having to meet special requirements (e.g. for the SDK). To achieve this, the ApplicationName in the WepApplicationBuilder is set to the library name:

WebApplication.CreateBuilder(options: new WebApplicationOptions()
{
ApplicationName = typeof(XyzBlazorHost).Assembly.GetName().Name
});

This enables access to the wwwroot elements and Blazor-specific JavaScripts such as blazor.web.js.

Until now, the entire project and its various dependencies ran on .NET 9.

Problem
After upgrading all relevant projects to .NET 10, blazor.web.js is no longer delivered. When the browser attempts to load blazor.web.js, it receives a 404 error. The reason for this problem is that Xyz.staticwebassets.runtime.json no longer contains a reference to these files. All attempts (and there were many) to change this with CsProj settings or via code were unsuccessful. I was also able to reproduce the problem with a brand new Blazor project from the standard template. As soon as you change the OutputType to ‘Library’, the corresponding assets are no longer included in the .staticwebassets.runtime.json file.

Workaround
As a workaround, I changed the SDK type from ‘Microsoft.NET.Sdk.Razor’ to ‘Microsoft.NET.Sdk.Web’ and removed the Library OutputType entry. To do this, I had to add a Main method to the project. Both steps (SDK and OutputType) were necessary.

Question
From my point of view, this behaviour does not make sense and is a bug – especially since I have not found any documentation on it. Is there at least one method to include Blazor-specific assets in .staticwebassets.runtime.json again, for example via a Project file switch? Should the default behaviour not be adjusted?

I consider shifting responsibility for the Blazor assets to the consuming project (which is possible via workarounds such as a Dummy.razor file) to be very messy and technically incorrect. If I move a completely autonomous Blazor website into a library, it should work without me having to adjust anything in the calling project.

Expected Behavior

It should not matter whether the project is a library or an executable project. Alternatively, it should at least be possible to change the behaviour under a library using a flag.

Steps To Reproduce

Create a new Blazor projekt. Change OutputType to "Library".

Exceptions (if any)

No response

.NET Version

10.0.100

Anything else?

Host:
Version: 10.0.0
Architecture: x64
Commit: b0f34d51fc

.NET SDKs installed:
9.0.308 [C:\Program Files\dotnet\sdk]
10.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 9.0.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 10.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 9.0.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 10.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.15 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 6.0.36 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 7.0.20 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 8.0.22 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 9.0.11 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 10.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

[javiercn]

@gemelo-Peer thanks for contacting us.

This is by design and a change that we implemented in 10.0 where we stop embedding the scripts into the Blazor assemblies. We expect Blazor web to run in the context of a web application and be an executable. Running Blazor Web from an RCL is not a documented feature nor supported, and we consider such thing undefined behavior that can break across any version.

The host project of the app is required to be an actual web app (that is reference the Microsoft.NET.Web.SDK and can either have a .razor file on it or use <RequiresAspNetWebAssets>true</RequiresAspNetWebAssets> to explicitly bring in the blazor JS assets).

[gemelo-Peer]

Thank you, Javier, for your quick response and clarification.

However, I must say that from a software design perspective, this is a very bad decision. It violates the principle of abstraction. If I have a library that provides a web page, a project that uses this library should not be dependent on the specific implementation of this functionality. In other words, the executing project should not care whether it is an ASP.NET Blazor implementation or whether the library itself opens a TCP/IP port and implements a web server there.

That is why I remain of the opinion that there must be at least a function that enables the library to provide everything necessary itself. I can't imagine that this would be particularly difficult to implement; it's just a design decision to remove this functionality from the library.

Regardless of this, I would like to emphasise that I consider Blazor to be a great technology.

[dotnet-policy-service]

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.