[.Net] Emits warning on common user patterns that may prevent ALC unloading

[Delsin-Yu]

Partially implemented:

• Provide a solid solution to help C# developers against "ALC unload failure" godot-proposals#11819

Related:

• .NET: Failed to unload assemblies. Please check <this issue> for more information. #78513

This is the Analyzer part of the proposal. The approaches for helping developers against the ALC unloading failures are:

1. An analyzer that flags certain use cases that prevent ALC from being unloaded, steering the developer away from writing ALC-incompatible code. (You are here)
2. At the framework level, implement well-known community cleanup workarounds on very frequently used BCL classes, enabling commonly used BCL functions that are frequently encountered when doing Tools development. (Not yet implemented, maybe implemented by another community member)

// e.g., System.Text.Json
void ClearJsonSerializerCache()
{
    var assembly = typeof(JsonSerializerOptions).Assembly;
    var updateHandlerType = assembly.GetType("System.Text.Json.JsonSerializerOptionsUpdateHandler");
    var clearCacheMethod = updateHandlerType?.GetMethod("ClearCache", BindingFlags.Static | BindingFlags.Public);
    clearCacheMethod?.Invoke(null, new object[] { null! });
}

3. Leak the not unloadable ALC and reload everything to a new ALC, bypass* the issue by leaking memory, making the C# functions of the editor stay up even if unloading has failed. (Not yet implemented, maybe implemented by another community member)
4. Auto-reboot the Editor when ALC leaks reach certain amounts, resolves the memory leak when lots of ALCs are stacking inside the memory. Maybe even surpasses number 3 if we can persist the current change assets & scene state very quickly, restart the project, and entirely fix .NET: Failed to unload assemblies. Please check <this issue> for more information. #78513. (Not yet implemented, maybe implemented by another community member)

The inspiration of # 1 and # 3 entirely comes from this two-line discussion, and the documentation of the Tool that Unity builds for helping their users on migrating to Modern .Net, the author of this PR read 0 line of the Unity's implmentation, and are very certain that the analyzer in this PR have minimum overlaps wit the Unity's implmentation (as we don't host the running game within the Editor, so we don't need all of the static variable resetting attribute shenanegins).

What happens when an assembly can’t be unloaded? What are the possible issues? Will there be two instances of types in that assembly: one from the newly loaded assembly and one from the one that couldn’t be unloaded? Will a newly instantiated object correctly use the new assembly?

Yes. We’re planning to report to the user after a suitable time that an AssemblyLoadContext has leaked.

AI Disclosure:

The Analyzer was developed by Opus 4.6 as the orchestrator, with GPT 5.4 serving as a subagent under the author’s supervision. The cases the analyzer targets to prevent ALC unloading have been rigorously validated using isolated MRP projects to ensure accuracy. The analyzer has been adapted for use in Godot.SourceGenerators.csproj by Opus 4.6, along with corresponding test suites. Additionally, the author manually modified some diagnostic warning messages to enhance clarity for general developers. A fresh instance of GPT 5.4 is also activated as an independent reviewer of the exact files modified in this PR to minimize inaccuracies.