[gelöst]Upgrade BC14->BC21OnPr viele Kompilierfehler al Konv

[Gollum83]

Hi Zusammen,
ich bräuchte bitte mal wieder Eurer Schwarmwissen.
ich versuche gerade testweise eine sehr große eigene Lösung von BC14 (CU18)zu einer höheren BC Version zu migrieren BC21 (CU2).
Die Lösung beinhaltet 100 % eigene Objekte, es werden keine MS Objekte verwendet.
Fürs Testszenario habe ich im ges. BC14 C/AL Code sämtliche .NET und Automation Verweise entfernt, um dies kümmere ich mich später,
ich wollte einfach unsere komplette Lösung in reinem C/AL Code durch den AL Konverter (txt2al) jagen
und schauen ob sich das als neue Extension dann zumindest kompilieren lässt, in eine frische BC21 Cronus Datenbank.
VSCode Projekt ist angelegt und Symbole können heruntergeladen werden.
Im Projekt ist als target OnPrem definiert.
Um eine Datenkonvertierung kümmere ich mich auch später, es soll wirklich nur um die Konvertierung der
eigenen Lösung von C/AL in eine neue al Extension gehen.

Zu meinem Erschrecken sind es, obwohl es reiner C/AL Codewar und in BC14 0 Kompilierfehler sind,
jetzt in VSCode über 600 Kompilierfehler.
Ich versuche nun die Fehlerarten etwas zu klassifizieren und dann im Bündel abzustellen.

Aber eine Fehlerart kann ich abs. nicht nachvollziehen,
es ist eigentlich ein ganz einfacher Fall:

-eine Page ruft eine Funktion einer Codeunit auf (mit Funktionsname "CheckUserEmployeeDataConfig"). Diese Codeunit ist in der Page als glob. Variable deklariert.
Der Funktionsaufruf ist rot unterkringelt, die Fehlermeldung sieht ungefährt so aus (habe den Firmenname, genauen Bezeichnungen etwas generalisiert...):
'Codeunit "XX RFQ Mgmt."' does not contain a definition for 'CheckUserEmployeeDataConfig'AL(AL0132)

In der entsprechenden Codeunit ist die Funktion ganz normal enthalten, aber mir fällt auf, dass ganz am Anfang der Codeunit
der Objektname rot unterkringelt ist und es ist dieser Kompilierfehler:
An application object of type 'Codeunit' with name 'XX RFQ Mgmt.' is already declared by the extension 'ExtName by ExtCreator (1.0.0.0)'AL(AL0197)
Die Meldung kann nicht korrekt sein, weder ein zweites Objekt mit gleichem Namen, noch zwei mal die gleiche ID ist in der Extension angelegt.
Durch einen Zufall, habe ich den Punkt des Codeunit Namens entfernt, und nun ist der Kompilierfehler weg.

-> kann es sein, dass in al keine Punkte mehr in den Objektnamen erlaubt sind?
-> jetzt kommt aber der Oberhammer. Nach Änderung des CU Objektnames wird dieser nicht in den anderen al Objekten mitgezogen,
die mit dieser Codeunit arbeiten.
Im alten Objekt Designer wurden ja alle Referenzobjekte automatisch mitgeändert.
Nur wenn ich in der besagten Page bei der Variable für die Codeunit auch den Punkt entferne,
wird die Codeunit und die aufgerufene Funktion erkannt.
Ist das wirklich Stand der Technik in der al Welt? Wenn ja, wie geht Ihr damit um?

Danke Euch im Voraus

Viele Grüße

Zuletzt geändert von Gollum83 am 20. Januar 2023 13:04, insgesamt 1-mal geändert.

Es gibt 'ne Möglichkeit de Bezüge automatisch mit ändern zu lassen, hab ich schon mal gesehen, kann aber nicht sagen wie weil ich in VS Code bzw. AL noch nicht wirklich aktiv bin. Punkte in Objektnamen sind ziemlich sicher weiterhin erlaubt.

danke Dir für die schnelle Antwort.
Ja das denke ich ist ja ein essentielles Feature,
wir haben Codeunits die werden über 100 mal wiederverwendet, manchmal auch in lokalen Variablen,
das alles manuell zu ändern wäre der Wahnsinn.

ok, danke Dir für die Info mit den Punkten.
Evtl. hat da der al Konverter irgendeinen Mist gemacht.
Klar ist jetzt BC14 CU18 auch nicht die neuste Version, gibt ja schon CU43,
aber eben auch nicht die älteste. Dass die da solche Bugs produzieren, glaube ich ja auch fast nicht...

[sweikelt]

"Rename Symbol" heißt hier das Zauberwort (F2)...und zwar auf der Codeunit - sprich stelle den Originalzustand wieder her, nutze F2 und lächle :)

Punkte sind weiterhin erlaubt => siehe z.B. COD 9

auch hilft es oft (jedenfalls mir), die Seite neu zu laden (Reload Window aus der Befehlspalette [STRG-SHIFT+P] )

PS: es gibt auch eine tolle Suche, mit der kannst du ebenfalls ganz viel hübsche Sachen machen (Suchen + Ersetzen im gesamten Projekt....auch mit Regex)

Zuletzt geändert von sweikelt am 11. Januar 2023 16:42, insgesamt 1-mal geändert.

Hallo,

ich habe das so angefangen:
Dateien mit txt2AL Konvertiert, und dann Datei für Datei in ein neues Projekt kopiert, bearbeitet und ergänzt um Prefix /Suffix, u.a. .

Für die Standardobjekte musst du dir sowieso neue Objekte anlegen, in denen du die Events ansprichst.

Ich hab noch kein Konvertierungstool gesehen, das man wirklich gebrauchen kann. Meistens funktionieren die gerade noch mit "Hello World" und dann ist Schluss.

Gruß Fiddi

Txt2AL würde übrigens in späteren CUs von v14 auch nochmal erweitert (tableDataOnly), ich würde dafür die neuste mögliche Version verwenden.

Punkte sollte man vermeiden, da diese schon Trennzeichen bei der File Naming Notation sind.

Im Projekt ist als target OnPrem definiert.

Das wird auf Dauer teuer, auch für interne Entwicklungen gelten die Lizenzanforderungen für Universal Code (Link)

danke Euch für die sehr hilfreichen Infos.

Das mit den Rename symbols habe ich gerade probiert, vielen dank. Ich habe damit das Objekt umbenannt, also . raus,
und habe schon knapp 200 Kompilierfehler weniger.
Super danke, nun weiß ich, dass diese wichtige Funktion geht.

Was allerdings unlogisch ist: ändere ich es mit diesem Tool wieder zurück, meckert das System schon wieder
bezüglich Objektname.
Es verhält sich wirklich so, dass bei mir keine Punkte erlaubt sind, keine Ahnung warum.

Wir benutzten/ändern keine MS Standard Objekte,
haben dafür aber ca. 1300 eigene. Wenn mir nicht mind. 90 % irgendein Konverter die arbeit abnimmt,
kommt vor der Fertigstellung der Umstellung eher mein Rentenbescheid, und ich bin noch nicht mal 40

Ich checke das nicht, warum mir das System keine . erlaubt, aber ich denke einige hundert Kompilierfehler könnte ich verringern,
wenn ich diese Punkte aus allen Objekte vorher entferne, aber das sind auch knapp 400 Objekte...


danke auch für die 2 ganz neuen infos gerade. ok, ich sehe, das mit den punkten muss raus.
das kann ich in BC14 noch bereinigen.
Zu OnPrem: ja ich weiß leider ,aber ich habe keine andere Wahl.
ich muss überhaupt mal schauen, dass ich dieses Jahr die riesige Migration auf OnPrem hinbekomme,
die Umstellung auf Cloud Code wird dann bestimmt nochmal 1-2 Jahre dauern. Bei so riesigen Lösungen ist da einfach viel dahinter

ich muss bitte nochmal fragen, ich hab schon wieder so ein komisches Phänomen:
In einer Codeunit in einer Funktionen, werden hintereinander 3 Funktionen einer Page aufgerufen.
Funktionsaufruf 1 passt, kein Kompilierfehler.
Bei Funktionsaufruf 2 und 3 jeweils wieder Kompilierfehler:
'Page "Pagename"' does not contain a definition for 'Funktionsmae'AL(AL0132)
Keine der beiden Objekte hat einen Punkt im Namen,
alle drei Funktionen sind in der Page im al file drin,nicht als lokal deklariert, und zeigen wiederum selbst keinen Kompilierfehler auf.
Alle drei Funktionen haben vorangestellt ein:
[Scope('Internal')]
Entwicklerfenster habe ich neu geladen

Ich verstehe es echt nicht...

wieviele Objekte habt ihr?
der Kompiler stellt sich manchmal echt ein wenig an

ca. 1300 Objekte

hab grad nochmal einen lustigen Fall:
in einer Page sind über 10 lokale Variablen angelegt,
die ersten paar kein Problem,
ab dann alle restliche Variablen Kompilierfehler.
Sind fast nur einfache Datentypen: Integer, Decimal, Text.
Bin jetzt drauf gekommen,
erstes Variable wo gemeckert wird, ist Verweis auf eine Page -> hier wieder mit . im Objektname
Folge: alle Variablen darunter, selbst einfachste Datentypen, alle als fehler markiert.
-> das werden bestimmt ein großer Teil meiner noch knapp 500 Kompilierfehler sein.
Gut dass ich das jetzt weiß, aber logisch ist das nicht...

alles sehr merkwürdig.
die Objektnamen sehen bei dir aber auch so aus, oder:

<objectType> <id> "objectName"

das stimmt

genau
so eine Codeunit, die mir der Kompiler ankreidet, da fängt das al file z.B. so an

codeunit 510xxxx "Irgendwas Mgmt."
{
....



der gesamte String "Irgendwas Mgmt." ist rot unterkringelt
und die zugeh. Meldung ist:
An application object of type 'Codeunit' with name 'Irgendwas Mgmt.' is already declared by the extension 'ExtName by ExtHersteller (1.0.0.0)'AL(AL0197)

die aber eben nicht stimmt, da diese Codeunit mit dieser ID wirklich nur einmal vorkommt, die ID ist unique und der Name der CU ebenfalls

es ist echt seltsam.

ich denke das beste wäre mal, in der BC14 in allen Objekten den Punkt zu entfernen
und alles nochmal über den al konverter laufen zu lassen

ich muss jetzt blos schauen, ob das über C/AL geht Objektname zu ändern, und zwar so, als ob der User dies im Objektdesigner machen würde,
damit die Referenzen sauber geändert werden
bei knapp 400 objekten würde ich sonst manuell eine Zeit lang sitzen...

An application object of type 'Codeunit' with name 'Irgendwas Mgmt.' is already declared by the extension 'ExtName by ExtHersteller (1.0.0.0)'AL(AL0197)

Dazu gibt es einige Issues bei GitHub, eventuell hilft das ja hier:
https://github.com/microsoft/AL/issues/7019

danke Dir, ich sehe mir das jetzt in Ruhe an und poste später das Ergebnis ob es geholfen hat

Hallo,
bin nun zum Testen gekommen:
in beiden settings.json Dateien war die Sektion für al.codeAnalyzers leer.

also die wie im anderen Forum beschriebene "${PerTenantExtensionCop} Eigenschaft war also nicht gesetzt.

Habe dann trotzdem 2 Versuche gemacht:

- die rad.json gelöscht, vscode schließen und neu öffnen
-vdie im beitrag beschriebenen "guten" settings in die beiden settings.json Dateien eingetragen + die rad.json gelöscht, vscode schließen und neu öffnen

der fehler ist immer noch da, leider...

Hallo Zusammen,

habe mich mittlerweile weiter mit dem Thema beschäftigt.
Insg. habe ich alle diese 4 Forumsseiten durchgeprüft:
https://github.com/microsoft/AL/issues/7019
https://www.365cycle.nl/dynamics/an-app ... -declared/
https://community.dynamics.com/business ... y-declared
https://github.com/microsoft/AL/issues/3618


Mein Verdacht war ja, dass es an den Punkten in den Objektnamen liegen könnte.

Die Theorie liegt "leider" vollkommen daneben.
Das Problem ist noch viel schlimmer.

Ich habe einen Fall gefunden, bei dem in einer Codeunit
eine Page mehrfach als lokale Varaible in versch. Funktionen angelegt ist.
Einige dieser lokalen Variablen werden ganz normal ohne Fehler angezeigt,
bei eingen Kommt ein Kompilerfehler.
Ich bin jetzt wirklich mit meinem Latein am Ende,
das ist dermaßen unlogisch
Bild 1 die Page die aufgerufen werden soll
Bild 2 eine Stelle mit Fehler
Bild 3 zeigt eine Stelle ohne Fehler

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Hallo,

lösche mal den VSCode- Cache unter "C:\Users\BENUTZER\AppData\Roaming\Code" die Verzeichnisse Cache und CacheData. Evtl. hilft das. auch im Projektverzsichnis in den .- Verzeichnissen gibt es auch manchmal einen Cache.
VS-Code vorher beenden nicht vergessen.

Gruß Fiddi

Danke Fiddi, das werde ich noch prüfen.

Ich arbeite gerade noch an den Hinweisen zu diesem Eintrag:
https://github.com/microsoft/AL/issues/1055
auch wenn ich ihn noch nicht verstehe.
Bei den Stellen mit Fehler ist die Page als Typ "Page" deklariert.
Mache ich nun wie in dem Forumseintrag ein "Pag" daraus, ist der Kompilerfehler weg

Was ist denn der Unterschied zwischen Page und Pag?

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

oder gerade entdeckt, noch so ein hauer:
in einer Codeunit ist eine Funktion definiert, ganz normal, nicht lokal.
Diese Funktion wird mehrfach in dieser Codeunit in anderen Funktionen aufgerufen.
Manche Aufrufe gehen, manche nicht
absolut unlogisch

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Für das Umbenennen von Dateien im Projekt sind etliche diffuse Bugs bekannt.
Beispiele:
https://github.com/microsoft/AL/issues/6077
https://github.com/microsoft/AL/issues/6214
https://github.com/microsoft/AL/issues/6278
Das betrifft auch Änderungen über Waldos CRS Tool, hier mit mit uppercase/lowercase.
https://github.com/waldo1001/crs-al-lan ... issues/265

danke Dir Kowa,
ich werde das alles in Ruhge durchschauen,
in dem Projekt in dem ich gerade bin, habe ich die Files noch nicht mit dem CRS Tool umbenannt
allerdings installiert ist es

Hallo Zusammen,

habe wegen meiner ganzen Fehler folgende 2 Dinge durchgeführt:

-habe den Tip von fiddi durchgeführt und die cache ordner geleert

-dann mal zur Sicherheit ein neues Projekt angelegt,
und versuchte im ersten Schritt einfach mal
von den ganzen konvertierten al files
nur mal eine einzige simple Tabelle mit 3 Felder + ebenso einfache Listen Page ins Projekt einzubinden.
Die Tabelle passt, bei der Page habe ich zwei Kompilierfehler.
Der mag bei allen 3 Feldern die Expression nicht, ich muss erst ein Rec. davor setzen.
Das habe ich wie im Screenshot zu sehen, mal für das erste Feld gemacht.

Bei den Feldern mit Fehler wird die Meldung:
The name 'RoHS Exemption' does not exist in the current context.AL(AL0118)
ausgegeben

Ist das bei Euch auch so? Ist doch irgendwie seltsam.

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

ah ja, genau und auch in der app.json mal auf neuere versionen eigestellt:
"platform": "1.0.0.0",
"application": "21.0.0.0",

"runtime": "10.0",