The AL Language server crashes with a stack overflow

Start with the attached minimal project and the stack trace in the issue; reproduce using AL 18.1.43.24897 with the two listed assemblies in the probing path, then compare with AL 17.10 and without System.Drawing.Common.dll. The trace points to CecilAssemblyResolver and recursive ExportedType.Resolve calls. Done means the compiler handles the forwarding cycle without crashing, at most reporting the type as unresolved.

Bug report

The AL Language server crashes with a stack overflow when it opens our base application project, and after 5 crashes VS Code shows "The AL server crashed 5 times in the last 3 minutes. The server will not be restarted." The command-line compiler (alc.exe) crashes the same way, exit code 0xC00000FD (3221225725).

The bug started in AL Language extension 18.x. It happens with 18.1.2842859 (compiler 18.1.43.24897). Version 17.10.2902953 compiles the same project with 0 errors.

Environment

• Project: Business Central 19 base application on the BC20 platform, "platform": "20.0.0.0", "runtime": "9.2", "target": "OnPrem"
• Local BC20 container created with BcContainerHelper
• Windows 11

al.assemblyProbingPaths:

[
  "C:\\ProgramData\\BcContainerHelper\\Extensions\\<container>\\.netPackages",
  "C:\\WINDOWS\\Microsoft.NET\\assembly"
]

Minimal repro (attached zip)
An empty project (platform 20.0.0.0, runtime 9.2, target OnPrem) with only this dotnet.al crashes alc.exe 18.1.43.24897 with a stack overflow (exit code 0xC00000FD). No variables are needed:

dotnet
{
    assembly("System.Windows.Forms")
    {
        Version = '4.0.0.0';
        Culture = 'neutral';
        PublicKeyToken = 'b77a5c561934e089';

        type("System.Windows.Forms.PrintDialog"; "PrintDialog")
        {
        }
    }
}

al.assemblyProbingPaths points to a folder with only two DLLs:

• System.Windows.Forms.dll 4.0.0.0 from .NET Framework 4.8 (GAC_MSIL)
• System.Drawing.Common.dll 6.0.0.0, file version 6.0.21.52210, from NuGet System.Drawing.Common 6.0.0 lib/net461 (BC20 ships this file in its Service folder)

Results:

• AL 18.1.43.24897: stack overflow
• AL 17.10.2902953: compiles, exit code 0
• AL 18.1 without System.Drawing.Common.dll in the folder: compiles, exit code 0

Probable cause
While loading the members of PrintDialog, System.Drawing resolves to the compiler's own .NET 10 runtime facade (Microsoft.NETCore.App\10.0.x\System.Drawing.dll, version 4.0.0.0). That facade forwards the drawing types to System.Drawing.Common. System.Drawing.Common resolves through the probing path to the 6.0.0.0 net461 build, which forwards the same types back to System.Drawing 4.0.0.0. That again resolves to the .NET 10 facade, so ExportedType.Resolve recurses until the stack overflows.

The compiler should not crash on a type-forwarding cycle. For OnPrem targets it should probably also prefer .NET Framework assemblies from the probing paths over its own runtime's facades.

Stack trace (trimmed)

Stack overflow.
   at Mono.Cecil.AssemblyNameReference.Parse(System.String)
   at Microsoft.Dynamics.Nav.CodeAnalysis.DotNet.AssemblyLocatorBase.GetAssemblyName(System.String)
   at Microsoft.Dynamics.Nav.CodeAnalysis.DotNet.AssemblyLocatorBase.GetPathToAssembly(System.String)
   at Microsoft.Dynamics.Nav.CodeAnalysis.DotNet.Cecil.CecilAssemblyResolver.Resolve(Mono.Cecil.AssemblyNameReference)
   at Mono.Cecil.MetadataResolver.Resolve(Mono.Cecil.TypeReference)
   at Mono.Cecil.ModuleDefinition.Resolve(Mono.Cecil.TypeReference)
   at Mono.Cecil.ExportedType.Resolve()
   at Mono.Cecil.MetadataResolver.GetType(Mono.Cecil.ModuleDefinition, Mono.Cecil.TypeReference)
   ... (the last four frames repeat until the stack overflows) ...
   at Mono.Cecil.TypeReference.Resolve()
   at Microsoft.Dynamics.Nav.CodeAnalysis.DotNet.Cecil.CecilDotNetTypeInfoProvider.GetTypeDefinition(Mono.Cecil.TypeReference)
   at Microsoft.Dynamics.Nav.CodeAnalysis.DotNet.Cecil.CecilDotNetTypeInfoProvider.GetReturnTypeInfo(Mono.Cecil.TypeReference)
   at Microsoft.Dynamics.Nav.CodeAnalysis.DotNet.Cecil.CecilDotNetTypeInfoProvider.BuildPropertyInfo(...)
   at Microsoft.Dynamics.Nav.CodeAnalysis.DotNet.Cecil.CecilDotNetTypeInfoProvider.BuildPropertyInfoList(...)
   at Microsoft.Dynamics.Nav.CodeAnalysis.DotNet.Cecil.CecilDotNetTypeLoader.LoadType(...)
   at Microsoft.Dynamics.Nav.CodeAnalysis.Symbols.SourceDotNetTypeDeclarationSymbol.LazyGetType()
   ...
   at Microsoft.Dynamics.Nav.CodeAnalysis.Symbols.SourceAttributeSymbol.CheckAttribute()
   at Microsoft.Dynamics.Nav.CodeAnalysis.Symbols.SourceVariableSymbol.ForceCompleteAttributes(...)
   at Microsoft.Dynamics.Nav.CodeAnalysis.Symbols.SourceCodeunitTypeSymbol.ForceComplete(...)

Expected behavior
The compiler should not crash on a type-forwarding cycle; at most it should report the type as unresolved.

Platform
Windows

5. Versions:

• AL Language extension active in VS Code: 18.1.2842859, the version that crashes

• Visual Studio Code: Version: 1.143.1 (user setup)

• Business Central application: 20.18.60911.0 (FI)

• Business Central platform: 20.0.60870.0

• Operating System:

  • [ X] Windows
  • Linux
  • MacOS