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.

[ghost]

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

[mkArtak]

@javiercn is right. We track improvements to single file publishing experience as part of #27888.
Will close this as a dupe. @maloo feel free to add comments to the linked issue, though this is already linked from there.

[maloo]

Ok, but to me this is a clear regression/bug since it worked fine in .NET 3.1 Core. And yes, I understand the way single file is implemented has changed. But I still see no technical reason to put this file outside the executable, it worked fine to have it in the extraction part in 3.1.
Do you have any other issue that detail why this file can't be included in the extraction part like all the native dlls? Maybe I can create a pull request with a fix?

[javiercn]

@maloo as @mkArtak mentions, we are tracking improvements here as part of #27888.

I want to set expectations here. We don't consider this a regression/bug because we decided to explicitly exclude the .Views assembly from the single file publish experience, due to the technical challenges involved in View resolution at runtime when single file publish is enabled. For that reason, it is very unlikely that we will patch this during the 5.0 timeframe.

We do have plans for 6.0 that will address this, but not for 5.0. I understand that this might not be what you are expecting to hear; while its desirable to have a single file for deployment, this is not a common scenario for web applications, specially when by default we don't embed static resources either.

We appreciate you want to contribute a fix, but unfortunately we don't think this is an easy fix nor anything we would feel confortable putting in a patch. As I mentioned, there are technical challenges with the way Razor works and the new way single file publish works, and we plan to tackle that as part of 6.0 with a different design.

I hope this helps clarify things.

[maloo]

I understand your point. But I would appreciate a pointer to an issue used to track these difficulties of View resolution in runtime. I can understand that the new memory mapped solution of single file can interfere. But I'm talking about the fallback solution of bundling and extracting the native files, just like was done for all files in 3.1. I don't know of any change in View resolution that would invalidate the solution to bundle the dlls in the exe and extract it before first run like 3.1. Technically that is the same as shipping it side by side. Unless there is a bug where the wrong executable path is used when loading the Views.dll (since the extract solution put it in a temp folder). Just hoping to get a pointer, so I don't have to dig through all of the msbuild stuff to fix this.
Appreciate you taking your time to respond :)

[javiercn]

@pranavkm can you provide details here?

[mkArtak]

@maloo wanted to also drop this here, as this is something we've discovered in 5.0 and fixed for the upcoming 5.0.1 release:: #27831 ?

[ghost]

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.