internal runtime API to return hot reload capabilities

[lambdageek]

MonoVM and CoreCLR will both support hot reload in .NET 6. However the actual set of supported (non-"rude") edits are different between the runtimes. In future releases the capabilities of both runtimes will evolve. Part of #44806 and #45629

Related roslyn issue: dotnet/roslyn#49010

In a hot reload editing session, the runtime and the Roslyn compiler (mediated by a communication mechanism such as dotnet watch or the Visual Studio debugger) will need to agree on the supported edits.

One approach would be to build into Roslyn the knowledge of the capabilities of each runtime based on the reported runtime version. However in this case it would be difficult to mix compiler and runtime versions. Also if the runtime wants to disable an edit in a servicing release, it would require closely coupling servicing releases of (potentially several) Roslyn versions and the runtime.

Another approach is to expose a new API implemented by the runtime that returns a list of the supported capabilities:

 namespace System.Reflection.Metadata
{
    partial class AssemblyExtensions
    {
        /// Returns a description of the supported System.Reflection.Metadata.AssemblyExtensions.ApplyUpdate edits.
        /// Returns string.Empty if applying updates is not supported by this runtime.
        internal static string GetApplyUpdateCapabilities ();
    }
}

The specific format of the return value would be implementation defined and in practice it would be a contract between the runtimes and Roslyn.

Example of capabilities description

(This is for illustration only and not part of the API definition)

For example the string might be a space separated sequence of tokens from the following set: Baseline, RuntimeEdits, AddDefinitionToExistingType, NewTypeDefinition. The proposal is to represent .NET 5 CoreCLR capabilities as Baseline plus everything that .NET 5 CoreCLR can do minus what .NET 6 MonoVM can do. That is, .NET 5 MonoVM would be represented by the empty set of capabilities, .NET 5 CoreCLR as Baseline plus everything that CoreCLR can do that .NET6 Mono cannot. In future releases, as MonoVM catches up it will start returning AddDefinitionToExistingType (for example). In future releases when one or both runtimes add a new capability, it will be added to the enumeration. In summary:

• .NET 5 CoreCLR, .NET Framework: "Baseline AddDefinitionToExistingType NewTypeDefinition " (and ... TBD based on Mono capabilities )
• .NET 6 CoreCLR: .NET 5 + "RuntimeEdits"
• .NET 5 MonoVM: ""
• .NET 6 MonoVM: "Baseline RuntimeEdits"

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.

[lambdageek]

/cc @tmat @mikem8361 @tommcdon

[jkotas]

We would define negative capabilities for Mono,

That looks weird. I think we should define this just in term of the possitive capabilities.

Is there a reason why not just use a flags enum for this?

[jkotas]

Potential alternative design is to avoid introducing a new API for this and just use the existing RuntimeFeature.IsSupported API. e.g. RuntimeFeature.IsSupported("AddFieldDefinition").

[tmat]

That looks weird. I think we should define this just in term of the possitive capabilities.

The assumption was that there wouldn't be that many negative and the set would be empty for .NET Framework/.NET 5.
Otherwise we would need to hard-code list of everything that .NET Framework, .NET 5 can do into the code that calls this API (since the runtimes do not have the API, the call would fail and the fall back would assume it's an older runtime).

Is there a reason why not just use a flags enum for this?

64 might not be enough bits.

[jkotas]

It would be useful to see the full set we expect to add for .NET 5.

HotReloadCapability

This should not be called HotReload. We have dropped "HotReload" from the apply delta API as well.

[tmat]

It would be useful to see the full set we expect to add for .NET 5.

For .NET 5, it would be an empty set - the same as .NET Framework.
For .NET 6 it would probably also be one item: RuntimeEditsSupported - which would indicate that we can apply changes while the app is running (as opposed to when suspended at breakpoint).

For Mono we are discussing the set here: dotnet/roslyn#49010 (comment).

Something like: RuntimeEditsSupported, AddDefinitionToExistingTypeNotSupported, AddNewTypeDefinitionNotSupported, etc. TBD

[tmat]

Good question. I think that would need to be special-cased as "nothing is supported".

[tmat]

For reference, here are all the current rude edits. They do not map to metadata edits directly, but you can get sense of what is reported.