Running ASP.NET Core application with PublishTrimmed set in visual studio makes Microsoft.AspNetCore.Watch.BrowserRefresh fail to execute

[davidfowl]

Describe the bug

When <PublishTrimmed> is set in the csproj, causes Microsoft.AspNetCore.Watch.BrowserRefresh to fail. I'm guessing hosting startups will fail when trimmed but I'm surprised this affects the developer experience.

To Reproduce

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <Nullable>enable</Nullable>
    <PublishTrimmed>true</PublishTrimmed>
  </PropertyGroup>

</Project>

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/", () => "Hello World!");

app.Run();

Exceptions (if any)

crit: Microsoft.AspNetCore.Hosting.Diagnostics[11]
      Hosting startup assembly exception
      System.InvalidOperationException: Startup assembly Microsoft.AspNetCore.Watch.BrowserRefresh failed to execute. See the inner exception for more details.
       ---> System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.AspNetCore.Watch.BrowserRefresh, Culture=neutral, PublicKeyToken=null'. The system cannot find the file specified.
      File name: 'Microsoft.AspNetCore.Watch.BrowserRefresh, Culture=neutral, PublicKeyToken=null'
         at System.Reflection.RuntimeAssembly.InternalLoad(ObjectHandleOnStack assemblyName, ObjectHandleOnStack requestingAssembly, StackCrawlMarkHandle stackMark, Boolean throwOnFileNotFound, ObjectHandleOnStack assemblyLoadContext, ObjectHandleOnStack retAssembly)
         at System.Reflection.RuntimeAssembly.InternalLoad(AssemblyName assemblyName, RuntimeAssembly requestingAssembly, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, AssemblyLoadContext assemblyLoadContext)
         at System.Reflection.Assembly.Load(AssemblyName assemblyRef)
         at Microsoft.AspNetCore.Hosting.GenericWebHostBuilder.ExecuteHostingStartups()
         --- End of inner exception stack trace ---

Further technical details

• ASP.NET Core version: Microsoft.AspNetCore.App 6.0.0-rc.1.21406.15

cc @pranavkm @eerhardt

[eerhardt]

I debugged this a bit today. The reason this is broken is because we disable Startup Hooks when PublishTrimmed=true. See dotnet/runtime#36526

When PublishTrimmed isn't set, the "Microsoft.AspNetCore.Watch.BrowserRefresh" assembly is already loaded in the process by the time the following code is invoked:

aspnetcore/src/Hosting/Hosting/src/GenericHost/GenericWebHostBuilder.cs

Lines 139 to 145 in 545d4ee

	// Execute the hosting startup assemblies
	foreach (var assemblyName in webHostOptions.GetFinalHostingStartupAssemblies())
	{
	try
	{
	var assembly = Assembly.Load(new AssemblyName(assemblyName));

So loading the assembly works, because it is already loaded.

When PublishTrimmed=true is set, Startup Hooks are disabled, which means the assembly isn't already loaded. And trying to load the assembly fails with "FileNotFoundException".

I'm guessing hosting startups will fail when trimmed but I'm surprised this affects the developer experience.

This is an intentional decision with PublishTrimmed. The intention is that dotnet run and dotnet publish apps should execute the exact same. Since Startup Hooks can't work with trimmed apps, we disable the feature by default when trimming. There are a number of other features that are disabled by default, see:

https://github.com/dotnet/sdk/blob/c3850ddbd2c92702cf62868d0614d35a1278f7bb/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.ILLink.targets#L31-L47

We recommend app devs set PublishTrimmed=true in their apps if they intend on trimming - see https://docs.microsoft.com/en-us/dotnet/core/deploying/trim-self-contained#trim-your-app---cli. This gives the most consistent behavior between F5/run and publish.

The ASP.NET SDK (or dotnet watch) can re-enable StartupHookSupport in MSBuild if it requires Startup Hooks to work at development time. Maybe based off Configuration=Debug?

cc @agocke @vitek-karas @sbomer @mateoatr

[mkArtakMSFT]

@davidfowl need your help to suggest what needs to happen and where. Thanks!

[davidfowl]

We probably need to enable this on launch from watch and from visual studio.

cc @vijayrkn @BillHiebert

[pranavkm]

The ASP.NET SDK (or dotnet watch) can re-enable StartupHookSupport in MSBuild if it requires Startup Hooks to work at development time. Maybe based off Configuration=Debug?

Given hot reload is a .NET feature, and is enabled by default for all .NET apps running from VS which also relies on startup hooks, configuring it in Microsoft.NET.Sdk would be the correct place. But at that point, should we have the trimmer targets configure it conditionally - https://github.com/dotnet/sdk/blob/main/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.ILLink.targets#L37

- <StartupHookSupport Condition="'$(StartupHookSupport)' == ''">false</StartupHookSupport>
+<StartupHookSupport Condition="'$(StartupHookSupport)' == '' AND '$(Configuration)' == 'Release'">false</StartupHookSupport>

[eerhardt]

Given hot reload is a .NET feature, and is enabled by default for all .NET apps running from VS which also relies on startup hooks

Can you point where hot reload depends on startup hooks (for non-ASP.NET projects)? I didn't know this, and would like to learn more.

cc @vitek-karas @agocke

[pranavkm]

The piece of code that receives hot reload deltas and calls MetadataUpdateHandlers is injected in to the app using a StartupHook. The code's similar to https://github.com/dotnet/sdk/blob/main/src/BuiltInTools/DotNetDeltaApplier/StartupHook.cs and used in F5 \ Ctrl - F5 and dotnet-watch.