Consider a hot reload feature switch for linking

[stephentoub]

Background and Motivation

We are going to have a variety of places across the core libraries that use MetadataUpdateHandlerAttribute to react to hot reload updates. Some of these handlers will have zero impact unless used (other than their presence in the library binaries) while others will have additional code on "normal" execution code paths, e.g. to track things that later need to be cleared. We should look at either using an existing feature switch (e.g. Debugging.IsSupported) or a new feature switch (e.g. AssemblyExtensions.IsApplyUpdateAvailable) that we tie all of these to and use to both link away and disable any expense when not required. We should aim to use the same switch across the whole stack (currently ASP.NET is using its own property).

Proposed API

namespace System.Reflection.Metadata
{
    public static class AssemblyExtensions
    {
        /// <summary>
        /// Returns true if the apply assembly update is enabled and available.
        /// </summary>
        public static bool IsApplyUpdateAvailable { get; }
    }
}

The .NET Core runtime will basically implement like this (and will cache the value in a static):

    IsApplyUpdateAvailable => Debugger.IsAttached || Environment.GetEnvironmentVariable("DOTNET_MODIFIABLE_ASSEMBLIES") != "" || Environment.GetEnvironmentVariable("COMPlus_ForceEnc") == "1";

The feature switch support in the runtime build files include this property so the conditional apply update code is elided on release builds.

Usage Examples

    if (AssemblyExtensions.IsApplyUpdateAvailable)
    {
        // Hot reload/ENC specific initialization or bookkeeping code
    }

The hot reload agent can use this to ensure that it can actually apply updates to the application. Third party libraries can use it to run some apply update specific initialization or bookkeeping code.

Risks

Low. This API is used only in very limited cases and by very few developers (mostly internal).

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

Tagging subscribers to 'size-reduction': @eerhardt, @SamMonoRT, @marek-safar, @tannergooding, @CoffeeFlux
See info in area-owners.md if you want to be subscribed.

Issue Details

---

We are going to have a variety of places across the core libraries that use MetadataUpdateHandlerAttribute to react to hot reload updates. Some of these handlers will have zero impact unless used (other than their presence in the library binaries) while others will have additional code on "normal" execution code paths, e.g. to track things that later need to be cleared. We should look at either using an existing feature switch (e.g. Debugging.IsSupported) or a new feature switch (e.g. HotReload.IsSupported) that we tie all of these to and use to both link away and disable any expense when not required. We should aim to use the same switch across the whole stack (currently ASP.NET is using its own HotReload.IsSupported).

cc: @eerhardt, @pranavkm

Author:	stephentoub
Assignees:	-
Labels:	size-reduction
Milestone:	6.0.0

Tagging subscribers to 'linkable-framework': @eerhardt, @vitek-karas, @LakshanF, @tannergooding, @sbomer
See info in area-owners.md if you want to be subscribed.

Issue Details

---

We are going to have a variety of places across the core libraries that use MetadataUpdateHandlerAttribute to react to hot reload updates. Some of these handlers will have zero impact unless used (other than their presence in the library binaries) while others will have additional code on "normal" execution code paths, e.g. to track things that later need to be cleared. We should look at either using an existing feature switch (e.g. Debugging.IsSupported) or a new feature switch (e.g. HotReload.IsSupported) that we tie all of these to and use to both link away and disable any expense when not required. We should aim to use the same switch across the whole stack (currently ASP.NET is using its own HotReload.IsSupported).

cc: @eerhardt, @pranavkm

Author:	stephentoub
Assignees:	-
Labels:	area-Meta, linkable-framework, size-reduction, untriaged
Milestone:	6.0.0

[pranavkm]

If I understand this correctly, would we be teaching the trimmer to remove all code paths inside a HotReload.IsSupported switch?

[SamMonoRT]

@lambdageek fyi

[eerhardt]

would we be teaching the trimmer to remove all code paths inside a HotReload.IsSupported switch?

If we added this switch, the trimmer would only remove code paths inside the HotReload.IsSupported switch when the switch was set to false.

There are other scenarios where the trimmer runs, but you still want to debug and hot-reload your app. One that comes to mind is Xamarin apps - See https://github.com/xamarin/xamarin-android/blob/main/Documentation/guides/OneDotNet.md#dotnet-build--publish.