MetadataUpdateHandler not working in custom host

[ikkentim]

Description

When using a custom host (using nethost/hostfxr), hot reloading works as expected (tested in Visual Studio), however, the metadata update handler as specified using the [MetadataUpdateHandler(..)] attribute does not trigger.

Since hot reloading works I expected the metadata update handler to work as well. Is this intended to work or not?

Reproduction Steps

Given the following managed code, uncommenting the line of code and hitting the hot reload button in Visual Studio, causes the console output to include the added line.

using ManagedLibrary;
using System;
using System.Reflection.Metadata;
using System.Runtime.InteropServices;

[assembly: MetadataUpdateHandler(typeof(ManagedWorker))]
namespace ManagedLibrary
{
    public class ManagedWorker
    {
        public static void ClearCache(Type[]? updatedTypes)
        {
            Console.WriteLine("ClearCache");
        }

        public static void UpdateApplication(Type[]? updatedTypes)
        {
            Console.WriteLine("UpdateApplication");
        }

        private static int _counter;

        [UnmanagedCallersOnly]
        public static void DoWork()
        {
            Console.WriteLine($"working! {_counter++}");
            // Console.WriteLine("changes made");
        }

        public static void Main()
        {
        }
    }
}

Full repro (managed+unmanaged) can be found here https://github.com/ikkentim/MetadataUpdateHandler-repro

• Build both projects, then launch (Debug) the ManagedLibrary using the provided launch profile.

Expected behavior

Changed output to appear in the console and a combination of ClearCache/UpdateApplication to be written to the console.

(...)
working! 6
working! 7
ClearCache
UpdateApplication
changes made
working! 8
changes made

Actual behavior

Changed output appears in the console, but neither ClearCache or UpdateApplication appears in the console.

(...)
working! 6
working! 7
changes made
working! 8
changes made

Regression?

No response

Known Workarounds

No response

Configuration

Microsoft.NETCore.App 9.0.0
Windows 10

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-reflection-metadata
See info in area-owners.md if you want to be subscribed.

[steveharter]

I did verify the repro.

Reaching out: @vitek-karas @stephentoub @jkotas : what is required for a custom host to work with [MetadataUpdateHandler] for hot reload?. Are there some startup hooks for example that need to be configured?

[dotnet-policy-service]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

[jkotas]

MetadataUpdateHandlers are executed by the debugger. Visual Studio debugger injects managed helper library into the process to help with that. This library is injected into the process via startup hooks.

StartupHooks are only executed by the runtime right before the application Main method gets executed. It explains why it does not work with your custom host since it does not have Main method.

As a workaround, you try calling an empty Main method in your custom host. Alternatively, you can execute the startup hooks from the custom host directly, but that's probably more complicated.

[ikkentim]

Where can I find the startup hooks? I checked the DOTNET_STARTUP_HOOKS environment variable from within the [UnmanagedCallersOnly] entrypoint, but it appears to be empty when running the managed app from Visual Studio with a custom launch profile to launch using the unmanaged host app. AppContext.GetData("STARTUP_HOOKS") is also empty. I also tried calling the internal method System.StartupHookProvider.ProcessStartupHooks, but it yielded no result.

regarding calling Main from the host:
How would I go about calling the main method if I also intend to use [UnmanagedCallersOnly] entrypoints?
The only way I'm aware I am able to call the entry point is using hostfxr_initialize_for_dotnet_command_line/hostfxr_run_app, but it sort of shuts down the CLR (according to #35329 (comment) ), so any subsequent calls to [UnmanagedCallersOnly] entrypoint cause a hang.

I don't really intend to use Main(), I only build as an executable instead of a library to generate a runtimeconfig. Preferable I just load the startup hooks myself

[jkotas]

I checked the DOTNET_STARTUP_HOOKS environment variable from within the [UnmanagedCallersOnly] entrypoint, but it appears to be empty when running the managed app from Visual Studio with a custom launch profile to launch using the unmanaged host app

It means that Visual Studio debugger does not setup the startup hooks with a custom launch profile.

@tommcdon This is Visual Studio debugger question. Could you please route it?