ALCops statt LinterCop – was AL-Entwickler in Business Central jetzt wissen müssen

Wer in den letzten Jahren für Microsoft Dynamics 365 Business Central in AL entwickelt hat, kennt ihn fast sicher: den BusinessCentral.LinterCop. Neben CodeCop, UICop, AppSourceCop und PerTenantExtensionCop von Microsoft war er für viele Teams der wichtigste zusätzliche Analyzer – Community-getrieben, praxisnah und in unzähligen Pipelines fest verbaut.

Damit ist jetzt Schluss. LinterCop ist deprecated, die Weiterentwicklung findet unter neuem Namen statt: ALCops.

Und das ist keine kosmetische Umbenennung. Spätestens mit AL Language v18, die rund um Oktober 2026 zum aktuellen Release wird, funktioniert LinterCop nicht mehr. Wer seine Builds stabil halten will, sollte die Umstellung also nicht auf die lange Bank schieben.

Diese Grafik wurde von uns erstellt und ist nicht KI-generiert.

Was ist ein Linter – und warum brauchen AL-Projekte einen?

Ein Linter (in der AL-Welt meist Code Analyzer oder Cop genannt) prüft den Quellcode schon beim Kompilieren auf Probleme, die der Compiler selbst durchlässt:

• Code, der zwar kompiliert, sich aber zur Laufzeit anders verhält als gedacht
• fehlende Captions, Tooltips oder Permissions
• unnötig komplexe Prozeduren
• uneinheitliche Formatierung und Benennung
• Muster, die bei Updates oder in der Cloud Probleme machen

Gerade in Business Central, wo Erweiterungen jedes Major-Update überstehen müssen, ist das ein echter Qualitätshebel. Ein guter Analyzer findet Fehler im Editor, nicht beim Kunden.

Die Historie: vom Community-Projekt zum Nachfolger

Diese Grafik wurde von uns erstellt und ist nicht KI-generiert.

Die Anfänge

Stefan Maron hat den BusinessCentral.LinterCop als Community-Projekt gestartet. Die Idee: Regeln, die Microsoft nicht (oder noch nicht) mitliefert, als zusätzlichen Analyzer bereitzustellen. Arthur van de Vondervoort hat das Projekt später maßgeblich weiterentwickelt – am Ende umfasste LinterCop fast 100 Regeln und eine große Contributor-Basis.

Die Schwachstellen wurden sichtbar

Mit dem Erfolg kamen strukturelle Probleme:

• Ein Analyzer für alles: AL-Sprachregeln, BC-Konventionen, Formatierung und Testcode lagen in einem einzigen Paket. Damit Pipelines nicht brachen, standen viele Regeln standardmäßig nur auf Info.
• Unhandliche Releases: Pro AL-Language-Version gab es eine eigene DLL – zuletzt Dutzende Assets pro Release, schwer zu pflegen und schwer zu pinnen.
• Abhängigkeit von GitHub-Releases: Als GitHub im Mai 2025 die Rate-Limits für nicht authentifizierte Anfragen verschärfte, schlugen Pipelines fehl, die die LinterCop-DLL direkt aus den Releases geladen haben.

Der Neustart als ALCops

Statt das bestehende Repository umzubauen – was bestehende Integrationen und Pipelines gebrochen hätte – hat Arthur van de Vondervoort im Februar 2026 mit ALCops einen sauberen Neustart vorgestellt. Bewusst nicht mehr unter einem persönlichen GitHub-Account, sondern als eigenständiges Projekt, das über eine einzelne Person hinauswachsen kann.

Das Ende von LinterCop

Im Mai 2026 folgte im LinterCop-Repository der offizielle Aufruf: „Migrate to ALCops before October 2026“. Die Eckdaten:

• LinterCop bekommt keine neuen Regeln und keine Fixes mehr.
• Die letzte unterstützte AL-Language-Version ist das Release vom 25. März 2026.
• Sobald AL Language v18 das aktuelle Release ist (erwartet um Oktober 2026), funktioniert LinterCop nicht mehr.
• Schon heute können Pre-Releases der AL Language automatisierte Builds mit LinterCop brechen.

💡 Kurz gesagt: Wer LinterCop noch in VS Code oder in der Pipeline nutzt, arbeitet ab jetzt auf Abruf. Die Migration ist kein „Nice to have“ mehr.

Was ist neu an ALCops?

Die auffälligste Änderung: Aus einem Analyzer werden sechs fachlich getrennte Analyzer. Teams können damit gezielt entscheiden, welche Domänen sie prüfen lassen wollen – und mit welcher Strenge.

Diese Grafik wurde von uns erstellt und ist nicht KI-generiert.

Dazu kommt ALCops.Common, das die gemeinsame Konfiguration lädt und immer eingebunden sein muss.

Weitere Neuerungen:

• Verteilung über NuGet statt über GitHub-Release-DLLs – mit Builds für net8.0 (AL 16+) und netstandard2.1 für ältere Versionen.
• Deutlich mehr Code-Fixes: rund 30 automatische Korrekturen statt einer Handvoll bei LinterCop.
• Korrektere Regeln: Viele Regeln wurden überarbeitet, etwa die TransferFields-Prüfung, deren Feld-Kopplungen neu aus den BC-Artefakten erzeugt wurden.
• Eigene VS-Code-Extension inklusive automatischer Updates.
• CI/CD-Unterstützung für AL-Go for GitHub, Azure DevOps und die Kommandozeile.
• MCP-Server (noch im frühen Stadium), mit dem KI-Coding-Agenten Analysen ausführen und Code-Fixes deterministisch über den Analyzer anwenden können.
• Ausführliche Dokumentation auf alcops.dev.

Die Migration in vier Schritten

Diese Grafik wurde von uns erstellt und ist nicht KI-generiert.

1. Inventur

Suchen Sie im Repository alle Stellen, an denen LinterCop-IDs (LC0001 bis LC0094) vorkommen:

• in *.ruleset.json-Dateien
• in #pragma warning disable|enable|restore-Direktiven in .al-Dateien
• in Pipeline-Skripten, die die LinterCop-DLL herunterladen

2. IDs mappen

Viele Regeln haben eine neue ID mit neuem Präfix bekommen, weil sie jetzt zu einem anderen Analyzer gehören:

LC0001  →  PC0001   (PlatformCop)
LC0004  →  AC0001   (ApplicationCop)
LC0002  →  DC0001   (DocumentationCop)
LC0024  →  FC0001   (FormattingCop)
LC0093  →  TA0001   (TestAutomationCop)

Einige Regeln wurden aufgeteilt oder zusammengelegt:

• Split: LC0009 und LC0010 haben bisher sowohl zyklomatische Komplexität als auch Maintainability Index geprüft. In ALCops sind das getrennte Regeln (LC0007/LC0009 bzw. LC0008/LC0010).
• Merge: LC0003 und LC0012 prüften beide hart codierte Objekt-IDs und sind jetzt in LC0003 vereint.
• Über Analyzer verteilt: LC0044 wird zu PC0020 und PC0021.

⚠️ Wichtig: Kein blindes Suchen & Ersetzen. Weil ALCops IDs teilweise neu vergibt und einzelne LC-Nummern jetzt für andere Regeln stehen, kann eine reine Textersetzung Regeln versehentlich falsch zuordnen. Nutzen Sie die Mapping-Tabelle oder das offizielle Migrationsskript.

Ein migriertes Ruleset kann zum Beispiel so aussehen – die justification dokumentiert dabei die alte ID:

{
  "name": "Projekt-Ruleset",
  "rules": [
    {
      "id": "PC0001",
      "action": "Warning",
      "justification": "Previously LC0001"
    },
    {
      "id": "AC0001",
      "action": "Warning",
      "justification": "Previously LC0004"
    }
  ]
}

Und aus

#pragma warning disable LC0001

wird

#pragma warning disable PC0001

3. Umstellen: VS Code und Pipeline

In VS Code deinstallieren Sie zuerst die LinterCop-Extension – beide Extensions können nicht parallel laufen, weil sie dieselben Diagnose-IDs verwenden. Anschließend installieren Sie die ALCops-Extension aus dem Marketplace und wählen über die Befehlspalette „ALCops: Select Code Analyzers“ die gewünschten Analyzer aus.

Alternativ lässt sich die Konfiguration direkt in der settings.json hinterlegen:

"al.codeAnalyzers": [
  "${CodeCop}",
  "${UICop}",
  "${analyzerFolder}ALCops.ApplicationCop.dll",
  "${analyzerFolder}ALCops.DocumentationCop.dll",
  "${analyzerFolder}ALCops.FormattingCop.dll",
  "${analyzerFolder}ALCops.LinterCop.dll",
  "${analyzerFolder}ALCops.PlatformCop.dll",
  "${analyzerFolder}ALCops.Common.dll"
]

Sie müssen nicht alle Analyzer aktivieren – ALCops.Common.dll gehört aber immer dazu.

In AL-Go for GitHub werden die Analyzer über customCodeCops in der .AL-Go/settings.json eingebunden:

"customCodeCops": [
  ".alcops/ALCops.ApplicationCop.dll",
  ".alcops/ALCops.DocumentationCop.dll",
  ".alcops/ALCops.FormattingCop.dll",
  ".alcops/ALCops.LinterCop.dll",
  ".alcops/ALCops.PlatformCop.dll",
  ".alcops/ALCops.TestAutomationCop.dll",
  ".alcops/ALCops.Common.dll"
]

Die DLLs selbst lädt ein Hook-Skript aus NuGet herunter (PipelineInitialize.ps1 bzw. bei aktivierter Workspace Compilation PreCompileApp.ps1). Für reproduzierbare Builds empfiehlt es sich, die Version dort explizit zu pinnen. Die genauen Skripte finden Sie in der AL-Go-Anleitung auf alcops.dev.

4. Prüfen und nachschärfen

Nach dem ersten Build mit ALCops sollten Sie mit neuen Meldungen rechnen. Das ist gewollt: Viele Regeln sind präziser geworden, einige neu hinzugekommen.

Typische Beobachtungen aus der Community:

• PC0037 empfiehlt Validate() statt direkter Zuweisung – sinnvoll, kann aber in bestehendem Code viele Treffer erzeugen.
• LC0095 meldet unbenutzte Parameter. In Event-Subscribern ist das oft unvermeidbar und kann gezielt per Ruleset abgeschwächt werden.
• FC0004 (alphabetische Reihenfolge von Permissions) kann mit automatischem Speichern und Formatieren kollidieren.

Unser Tipp: Starten Sie nicht mit „alles auf Error“. Legen Sie fest, welche Analyzer für Ihr Projekt wirklich relevant sind, und schärfen Sie das Ruleset schrittweise nach – idealerweise gemeinsam im Team.

Praxiserfahrungen aus unseren Projekten

In unseren Business-Central-Projekten nutzen wir Code-Analyzer nicht als Selbstzweck, sondern als Sicherheitsnetz für Updates. Gerade bei Erweiterungen, die über Jahre gepflegt werden, zahlen sich saubere Events, korrekte Permissions und nachvollziehbare Komplexität spätestens beim nächsten Major-Update aus.

Dabei zeigt sich immer wieder:

• Die Aufteilung in Domänen hilft. Ein Kundenprojekt braucht selten dieselbe Strenge bei der Dokumentation wie eine AppSource-App. Mit ALCops lässt sich das endlich sauber trennen.
• PlatformCop-Meldungen sind fast nie Kosmetik. Hier stecken häufig echte Fehlerquellen, etwa bei Filtern, Record-Operationen oder API-Pages.
• Die Migration ist überschaubar – wenn man sie bewusst angeht. Der größte Aufwand liegt meist nicht im Umstellen der IDs, sondern im Sichten der neuen Meldungen.

Wenn Sie wissen möchten, wie wir AL-Code strukturieren, lesen Sie auch unsere Beiträge zu Event-Subscriber Best Practices und SingleInstance-Codeunits.

💡 Merksatz: Ein Linter ersetzt kein Code-Review – aber er sorgt dafür, dass sich das Review um Fachlichkeit dreht statt um vergessene Tooltips.

Vorteile auf einen Blick

• Zukunftssicher: ALCops wird aktiv weiterentwickelt und unterstützt neue AL-Language-Versionen.
• Modular: Sechs Analyzer, die sich einzeln aktivieren und konfigurieren lassen.
• Stabile Pipelines: Verteilung über NuGet statt über rate-limitierte GitHub-Releases.
• Mehr Automatik: Rund 30 Code-Fixes beschleunigen das Aufräumen bestehender Projekte.
• KI-ready: Über den MCP-Server können Coding-Agenten Analysen und Fixes nutzen.
• Gut dokumentiert: Jede Regel ist auf alcops.dev beschrieben – inklusive Migrationshilfe.

Fazit

Der BusinessCentral.LinterCop hat die AL-Community jahrelang begleitet und die Codequalität in unzähligen Business-Central-Projekten verbessert. Mit ALCops wird dieses Erbe nicht nur fortgeführt, sondern technisch sauber neu aufgestellt.

Die klare Empfehlung: Migrieren Sie jetzt. Mit AL Language v18 endet die Funktionsfähigkeit von LinterCop – und eine geplante Umstellung ist deutlich angenehmer als ein roter Build am Montagmorgen.

Sie brauchen Unterstützung bei Business Central?

Ob ALCops-Migration, Aufbau einer AL-Go-Pipeline oder die Entwicklung updatesicherer Erweiterungen: Wir unterstützen Unternehmen und Partner bei Beratung und AL-Entwicklung rund um Business Central – mit direktem Draht zum Entwickler.

👉 Mehr über unsere Business-Central-Leistungen 👉 Direkt Kontakt aufnehmen

Weiterführende Links

• ALCops – Dokumentation
• ALCops – Migration von LinterCop
• GitHub: Migrate to ALCops before October 2026 (Issue #1227)
• Arthur van de Vondervoort: ALCops – The Next Chapter of LinterCop