Enable Hot Reload startup hook loading in apps that enable PublishAot

[tmat]

Setting PublishAot to true disables startup hooks (StartupHookSupport is set to false).
This in turn disables Hot Reload since Hot Reload needs startup hook to function.

The reason why StartupHookSupport is disabled even in Debug builds is that we don't want the behavior of the application to differ between Debug and Release build.

If a customer wants to use Hot Reload they can StartupHookSupport property in the project to true. This effectively defeats the purpose of the default value.

Proposal

Special case Hot Reload startup hook assembly (e.g. by name) and load it even when startup hooks are disabled.

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @dotnet/ilc-contrib
See info in area-owners.md if you want to be subscribed.

[jkotas]

Special case Hot Reload startup hook assembly (e.g. by name) and load it even when startup hooks are disabled.

I do not think we want to do special casing for VS specific .dlls in the runtime like that.

Would it make sense to enable StartupHookSupport for debug builds only in the SDK?

[tmat]

I do not think we want to do special casing for VS specific .dlls in the runtime like that.

How about using a different environment variable name? E.g. DOTNET_HOT_RELOAD_STARTUP_HOOK or DOTNET_DEBUG_STARTUP_HOOKS

Would it make sense to enable StartupHookSupport for debug builds only in the SDK?

That would enable loading other hooks and potentially change the application behavior between release and debug. My understanding is that is undesirable.

[jkotas]

Simulation of the release build behavior in debug builds is best effort. It is not perfect and it is a non-goal for it to be perfect.

I do not think that the primary reason for disabling startup hook for trimmed and aot apps is high fidelity behavior simulation.

The primary reason for why StartupHook is disabled for trimmed apps (<PublishTrimmed>true</PublishTrimmed>) is that startup hook is nearly guaranteed to break apps published with trimming (it is very likely that something that the startup hook needs is going to be trimmed in the app). PublishAot gets the disabled startup hook by virtue of sharing the trimming defaults with PublishTrimmed.

[agocke]

I think it would be nice if we could narrow the allowance down to specific components that we know don't affect the published app (e.g., hot reload) but I also think it may be overkill to build a more complicated feature just for this.

In general I don't think the Debug/Release distinction matters that much for trimming compatibility though. One of the major goals is that debugging (in debug mode) shouldn't have notably different behavior between the trimmed and non-trimmed apps. It just so happens that in this case it won't because hot reload is a design-time only feature. Ideally we would only allow design-time startup hooks in PublishAOT, debug or release, but I don't know how to implement that.

[tmat]

@DamianEdwards FYI

[tmat]

The primary reason for why StartupHook is disabled for trimmed apps (true) is that startup hook is nearly guaranteed to break apps published with trimming (it is very likely that something that the startup hook needs is going to be trimmed in the app). PublishAot gets the disabled startup hook by virtue of sharing the trimming defaults with PublishTrimmed.

Yes, that's understood. The issue is that we don't have a way to distinguish between hooks that only apply to design-time and those that apply to the published app as well.

The former can be allowed. They will not be broken by trimming - no trimming is applied at design time. Also, if we had this explicit distinction it would be clear that the app behavior differences between design-time and the published app are limited to these design-time only hooks.

[jkotas]

I do not think we want to start growing parallel runtime configuration settings that only apply at design time. The startup hook is not the only problem. There are other features that are disabled by default in published trimmed or aot apps (e.g. tracing - EventSource support) that the debuggers and similar diagnostic tools use at design time for best experience.

I see this as an instance of the build vs. publish problem in the SDK. We want one runtime configuration to be used for (design time) builds and a different runtime configuration to be used for published apps. I think this issue should be fixed in the SDK.

[agocke]

Is your argument that the debug configuration is close enough to what we want that we should use that instead? I can live with that. @sbomer ?

[tmat]

@agocke I think it'd be reasonable to say we have 3 different configurations: 1) Debug, 2) Release 3) Published Release, with increasing differences. Behavior of (2) and (3) should be as close as possible. There can be more behavior differences between (1) and (2).