Make it statically and dynamicaly discoverable if runtime supports assembly unloading

[VSadov]

Just thought of a runtime capability, that would be convenient to check for - ability to unload types/assemblies.

I have seen many examples where code goes to great lengths trying to not retain runtime type objects - do not put types as keys (unless the type is a known primitive) in Dictionaries/Caches, do not cache delegates .... - That is with the assumption that retaining type objects will prevent assembly unloading.

However, if I am not mistaken, only a few, if any, runtimes can actually unload types/assemblies.

It would be helpful for the dynamic scenarios, to know if unloading is not possible and thus no need to worry about, for example, using type objects as keys in caches.

Proposed API

(part of overall capability probing framework as in https://github.com/dotnet/corefx/issues/17116)

public static readonly string CollectibleAssemblies = nameof(CollectibleAssemblies);

Any better name is more than welcome.

Any already existing conventional way to probe for the above would be fine too.

[jkotas]

Wouldn't you rather want to have an API that checks whether given type is unloadable?

[VSadov]

@jkotas - yes Type.IsUnloadable would be very useful, if it is reasonably fast - like if the answer is cached on the type object.

Most scenarios that I have seen actually have some heuristics to assume that primitives, arrays of primitives, some common generic instantiations are not unloadable.
That unfortunately gets expensive very quick, if digging deeper, and, most frustratingly, "yes" result cannot be cached :-).

Having Type.IsUnloadable, a general CollectibleAssemblies probe might still be useful - to elide all checking whatsoever, but in many cases Type.IsUnloadable would work better.

[jkotas]

Covered by dotnet/corefx#25671