proj.Views.dll not included in single file publish of Blazor project

[maloo]

Describe the bug

After upgrading a Blazor 3.1 project to net50, single file publish seems broken. There is one extra dll generated, called .Views.dll. It is just 18kB and only contains a type called Pages__Host. If this dll is removed, the project fails at runtime with something like "Cannot find the fallback endpoint specified by route values: { page: /_Host, area: }"

To Reproduce

I have not managed to repro it outside our project. I hope you will know where I can look to find a solution for this. If you have some pointers I might be able to create a small repro that I can share. Maybe there is some code that needs to be updated in Startup etc when migrating Blazor 3.1 to 5.0 related to this.
I also found a test case here:

aspnetcore/src/Razor/Microsoft.NET.Sdk.Razor/integrationtests/BuildWithComponents31IntegrationTest.cs

Line 18 in 0d8d4e7

[InitializeTestProject("blazor31")]

This seem related, and it says something about Blazor 3.1 which I migrated from. But from the test it looks like the Views.dll file should exist and contain this Pages__Host type, but what I don't understand is why it is not included in the single file published.

Exceptions (if any)

Note, this is only if I remove the Views.dll, which I understand I can't. But just wanted to see if it was used since I published for single file.
fail: Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware[1]

  An unhandled exception has occurred while executing the request.

  System.InvalidOperationException: Cannot find the fallback endpoint specified by route values: { page: /_Host, area:  }.

     at Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.DynamicPageEndpointMatcherPolicy.ApplyAsync(HttpContext httpContext, CandidateSet candidates)

     at Microsoft.AspNetCore.Routing.Matching.DfaMatcher.SelectEndpointWithPoliciesAsync(HttpContext httpContext, IEndpointSelectorPolicy[] policies, CandidateSet candidateSet)

     at Microsoft.AspNetCore.Routing.EndpointRoutingMiddleware.<Invoke>g__AwaitMatch|8_1(EndpointRoutingMiddleware middleware, HttpContext httpContext, Task matchTask)

     at Microsoft.AspNetCore.Diagnostics.ExceptionHandlerMiddleware.<Invoke>g__Awaited|6_0(ExceptionHandlerMiddleware middleware, HttpContext context, Task task)

Further technical details

• ASP.NET Core version:
  5.0.0
• Include the output of dotnet --info:
  .NET SDK (reflecting any global.json):

Version: 5.0.100

Commit: 5044b93829

Runtime Environment:

OS Name: Windows

OS Version: 10.0.17763

OS Platform: Windows

RID: win10-x64

Base Path: C:\Program Files\dotnet\sdk\5.0.100\

Host (useful for support):

Version: 5.0.0

Commit: cf258a14b7

.NET SDKs installed:

3.1.403 [C:\Program Files\dotnet\sdk]

5.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:

Microsoft.AspNetCore.All 2.1.23 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]

Microsoft.AspNetCore.App 2.1.23 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]

Microsoft.AspNetCore.App 3.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]

Microsoft.AspNetCore.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]

Microsoft.NETCore.App 2.1.23 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

Microsoft.NETCore.App 3.1.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

Microsoft.NETCore.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

Microsoft.WindowsDesktop.App 3.1.9 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Microsoft.WindowsDesktop.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

• The IDE (VS / VS Code/ VS4Mac) you're running on, and it's version:
  dotnet publish -r win7-x64 -c Release -p:PublishSingleFile=true -o publish

[maloo]

@pranavkm

[maloo]

We also use the IncludeNativeLibrariesForSelfExtract option, but that only includes the native dlls. Maybe that option needs to be extended to include this xx.Views.dll file or another option added for this.
Also, any attempt at trimming for Blazor apps seems to fail at startup with FileNotFoundException for System.Runtime, so single file deploys doesn't feel very stable at the moment.

[maloo]

I think I found a basic repro:

• Create a new blazorserver project and a console project
• Change blazor project into a Library
• Reference blazor project from console project
• Publish single file
  (I also moved blazor program.cs content into console program.cs, so I had to use Startup instead of Program in the router component assembly reference)

Building just a new blazorserver app outputs a Views.pdb, but no dll. But the above config output proj.Views.dll too.

[javiercn]

@maloo thanks for contacting us.

This is by design, the .Views dll is not included by default in the single file bundle.

/cc: @pranavkm in case he wants to add anything.

[maloo]

@javiercn ok, if this is by design, the fact that by default it is not included. How do I get it included? If I build single file publish I expect a single file, not two ;)
I can include All other .NET dlls, All native dlls, All wwwroot files and all config in single file publish, except this one 18kB file with one type in it. This can only be a design bug if it is by design :) And all this worked fine in 3.1.

[javiercn]

@maloo the way single file publish works in .NET Core 3.1 is significantly different to how it works in .NET 5.0 and as a result of that we could not make the Views.dll part of the bundle.

I'm not sure what you are doing to make the wwwroot files included in the bundle while making it work, since they are not included by default, but you could try and do the same thing for the Views assembly.

[maloo]

For wwwroot I just use the embedded file provider, I assume the same way Blazor main files are provided without being in wwwroot. But you can't make a Blazer server dll available for client download, it makes no sense. If you could not make it part of the new memory mapped single file solution, fine, that is just like the native dlls. But then you should make sure you include it in the "3.1 extract option" added in 5.0 to handle these special files that can't use direct mapping or merging. The option I mean is the new IncludeNativeLibrariesForSelfExtract. This option is exactly to handle this case. And even if your file is not native, it falls between the gap of this new option and merging in the single exe. So I can only see two options here:

1. Include it in the extraction like in 3.1 if IncludeNativeLibrariesForSelfExtract is set
2. Create a new option like IncludeSpecialManagedLibrariesForSelfExtract

[javiercn]

@maloo I'm not familiar with the details of why we decided to go this way. I'll let @pranavkm comment since he was directly involved on it, but I'm sure they thought about the options and came to the conclusion that this was a reasonable trade-off.

I understand your desire to have a truly single executable, if that is what you want, you can probably do something in MSBuild to make it happen (I have no idea what).

We might do improvements in this area in 6.0, however that's not something we support in 5.0.

I'll let @pranavkm add his comments here from now on, since I'm not an expert in this area and don't have much else to add.

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.

[maloo]

@javiercn please reopen this, it is Not resolved