ALC and server working differently for DotNet methods with optional arguments

[MODUSCarstenScholling]

1. Describe the bug ALC and server compiler working differently for DotNet methods with optional arguments. While omitted optional arguments are allowed and not causing any issues in ALC/VSCode, the server raises a runtime error when optional arguments to methods are missing.

2. To Reproduce You need a BC instance allowing target OnPrem.

1. Extract the following AL project MicrosoftIssues.zip
2. From the target BC service, copy the file Microsoft.Dynamics.Nav.CodeAnalysis.dll to .netpackages subfolder
3. Open workspace file in VSCode
4. Compile/Package and publish the the app (note that compiling and packaging works)
5. In customer list, click Actions -> "Not Working"

3. Expected behavior When clicking Actions -> "Not Working", no runtime error should occur. The called method should be identified correctly taking optional arguments into account.

4. Actual behavior When clicking Actions -> "Not Working", the following error occurs: A call to Microsoft.Dynamics.Nav.CodeAnalysis.Packaging.NavAppPackageReader.Create failed with this message: The type of one or more arguments does not match the method's parameter type.

5. Versions:

• AL Language: 13.0.937154
• Visual Studio Code: 1.86.1 (system setup)
• Business Central: Version: DE Business Central 23.4 (Platform 23.0.15712.0 + Application 23.4.15643.15715)

6. Information

public static NavAppPackageReader Create(Stream stream, bool leaveOpen = false, string? packagePath = null)

The called .net method contains optional arguments leaveOpen and packagePath. While VSCode/ALC allows to only specify stream, the BC server requires all arguments to be specified to identify the method.

    assembly("Microsoft.Dynamics.Nav.CodeAnalysis")
    {
        Culture = 'neutral';
        PublicKeyToken = '31bf3856ad364e35';

        type("Microsoft.Dynamics.Nav.CodeAnalysis.Packaging.NavAppPackageReader"; M365DotNetNavPackageReader) { }
        type("Microsoft.Dynamics.Nav.CodeAnalysis.Packaging.NavAppManifest"; M365DotNetNavAppManifest) { }
    }

    local procedure NotWorking()
    var
        navAppPackageReader: DotNet M365DotNetNavPackageReader;
    begin
        navAppPackageReader := navAppPackageReader.Create(GetApp(), false);
    end;

    local procedure Working()
    var
        navAppPackageReader: DotNet M365DotNetNavPackageReader;
        nullString: DotNet String;
    begin
        Clear(nullString);
        navAppPackageReader := navAppPackageReader.Create(GetApp(), false, nullString);

        Message(navAppPackageReader.ReadNavAppManifest().AppName());
    end;

[thloke]

The issue here isn't that ALC is behaving differently from the server, but the version of the dlls backing the DotNet type are different. We've recently changed the definition of NavAppPackageReader::Create which leads to the difference between what your local ALC run thinks is valid and what the server thinks is valid.

Given that these are internal types, we do not make any guarantees about their interfaces changing and we can and do change them as necessary.