Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AS0064 is thrown even if interface is Access=Internal #7968

Open
4 of 6 tasks
bjarkihall opened this issue Feb 12, 2025 · 0 comments
Open
4 of 6 tasks

AS0064 is thrown even if interface is Access=Internal #7968

bjarkihall opened this issue Feb 12, 2025 · 0 comments
Labels
accepted AppSourceCop This is a specific static-code-analysis group (AS)

Comments

@bjarkihall
Copy link

bjarkihall commented Feb 12, 2025

Please include the following with each issue:

1. Describe the bug
When removing/renaming/changing an internal interface (interface with Access = Internal;), we get an error:
"Interface implementations that have been published must not be deleted."
https://learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/analyzers/appsourcecop-as0064

2. To Reproduce
Steps to reproduce the behavior:

Here's a minimal AL repro:

// Version 1.0:
interface IFoo {
    Access = Internal;
    procedure Bar();
}

codeunit 50000 Foo implements IFoo
{
    procedure Bar()
    begin
        Message('Bar');
    end;
}
// Version 2.0:
interface IFoo2 { // Note: we changed the name
    Access = Internal;
    procedure Bar();
}

codeunit 50000 Foo implements IFoo2 // Note: we changed the implements (IFoo no longer exists, which causes the error, but it shouldn't)
{
    procedure Bar()
    begin
        Message('Bar');
    end;
}

or

// Version 2.1:
// Note: we removed the interface

codeunit 50000 Foo // Note: codeunit no longer implements an internal interface
{
    procedure Bar()
    begin
        Message('Bar');
    end;
}

3. Expected behavior
If the interface is public, dependent extensions can break, because they can reference it.
But since the interface is internal, we expect no error to be thrown, because there shouldn't be a way dependent extensions might break, like the docs indicate to justify the rule.

4. Actual behavior
We get an error when we don't expect to.

Note: Only related issue I found was this, which didn't seem to address the issue directly:
#7662

5. Versions:

  • AL Language: 15.0.1290655, build server throws using compiler with version 14.x
  • Visual Studio Code: 1.97.0 (but I think it's irrelevant of the issue)
  • Business Central: 25.3
  • List of Visual Studio Code extensions that you have installed:
    Only AL Language Extension (pre-release), but it happens on stable-version as well
  • Operating System:
    • Windows
    • Linux
    • MacOS

Final Checklist

Please remember to do the following:

  • Search the issue repository to ensure you are reporting a new issue

  • Reproduce the issue after disabling all extensions except the AL Language extension

  • Simplify your code around the issue to better isolate the problem

Internal work item: AB#565671

@thpeder thpeder added AppSourceCop This is a specific static-code-analysis group (AS) accepted labels Feb 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accepted AppSourceCop This is a specific static-code-analysis group (AS)
Projects
None yet
Development

No branches or pull requests

2 participants