[Gelöst] Codeänderung durch Compiler mit Kommentarzeilen

Das beim Kompilieren gelegentlich Codemüll entstehen kann, wenn eine Funktion und ein Feld die gleiche ID haben und letzteres gelöscht wird, ist ja leider nichts neues.

Beim Kompilieren mit NAV 2013 R2 Update 9 ist jetzt aber ein Codemüll mit einem neuen Fehler entstanden, den ich so noch nie gesehen habe.
Es wurden durch den Compiler Kommentarzeilen mit ihrem Inhalt in andere Codezeilen eingefügt, jeweils ohne die Auskommentierungszeichen //, mal darüber, mal darunter.
Im Bild sind Ausschnitte aus
Links: Codeunit 12 in der CH-Version, Mitte: DE-Version + Addon und rechts der Codemüll, den ich so manuell nicht gemergt habe, automatisch wurde dabei auch nichts gemergt. Dieser wurde aber nach dem erfolgreichen Kompilieren von NAV exportiert.

CodeGarbageCompiler.png

CodeGarbageCompiler2.png

Kennt jemand diesen Effekt bzw. weiss wodurch er ausgelöst wird?

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

Würde ja bedeuten das es bei fast jeden kompilieren solche Fehler geben müsste, oder?
Gerade wenn man den Quelltext gut ausdokumentiert hat.

Warum ist das auch bisher noch niemanden aufgefallen?

Ist es also nur ein Problem beim Txt-Export oder ist das Objekt im NAV so gespeichert?

mfg,
winfy

Ist es also nur ein Problem beim Txt-Export oder ist das Objekt im NAV so gespeichert?

Der Code wurde beim Kompileren auch innerhalb von NAV so verändert.

Also ein Fehler in der Txt-Import Routine?

Könnte es dann theoretisch nicht auch passieren das die gleichen exportierten Txt Objekte beim importieren anders (falsch) kompiliert werden?

mfg,
winfy

Vor dem Import sahen die Textdateien normal aus, Mergefehler sehen anders aus.

Hier ein "Müllplatz" aus Tabelle 81.

CodeGarbageCompilerTAB81.png

CodeGarbageCompilerTAB81_teil2.png

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

Mergefehler sehen anders aus.

Hast du dir deine gemergten Datei mal in Notepad++ oder Notepad2 usw. angesehen, ob es da evtl. doch andere Zeichen gibt?
Wenn das wirklich so ist wie du sagst, dann ist das ein Supergau.

mfg,
winfy

Hast du dir deine gemergten Datei mal in Notepad++ oder Notepad2 usw. angesehen, ob es da evtl. doch andere Zeichen gibt?

Außer den üblichen CRLF ist da nichts enthalten. Das Mergetool, mit dem ich das manuell gemergt habe, nutzen wir auch schon seit Jahren.

CodeGarbageCompiler3.png

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

Hmm, sieht schon komisch aus. Ich habe leider keine OPplus Objekte im Zugriff, ansonsten hätte ich das mal getestet.
Ich kann nicht ausschließen, dass eure spezielle Kodierung mit // und ----- hier Einfluss auf das Problem hat.
Kannst du das speziell mit den genutzten Kommentaren mal in einer unabhängigen Codeunit testen?

Ich kann nicht ausschließen, dass eure spezielle Kodierung mit // und ----- hier Einfluss auf das Problem hat.

Das nutzen wir auch schon seit Jahren, bislang ohne Probleme.
So sieht das im Code aus:

Code:

// gbedv OPP ------------------------------------------------- BEGIN
// gbedv OPP ------------------------------------------------- END

Außer den üblichen CRLF ist da nichts enthalten. Das Mergetool, mit dem ich das manuell gemergt habe, nutzen wir auch schon seit Jahren.

interessant wäre, was euer Compare-Tool hier erzeugt hat bevor du es in NAV Importiert hast. Und dann bitte mal alle Stringkonstanten des Textfiles anschauen, das sieht nach einem Referenz/Indexfehler des Parsers aus, der muss nicht erst dann auftreten, wenn du es im NAV- Code siehst

Gruß, Fiddi

Durch "willenloses" Einfügen dieser Zeilen kann ich das Problem nicht nachvollziehen. Kannst du mir, gerne per PM, mal die CU12 und ggf. die anhängenden Tabellen schicken, damit sie kompilierbar ist?

Das es etwas mit unser Kommentiermethode zu tun hat, ist eher unwahrscheinlich.
Hier sieht man den kurzen Kommentar // batch job aus dem CH-Standard in Tabelle 81, der auch rechts in der Mergeversion verschwunden ist, dafür wurde das Leerzeichen darunter mit einem Kommentar von uns gefüllt.

CodeGarbageCompiler4.png

interessant wäre, was euer Compare-Tool hier erzeugt hat bevor du es in NAV Importiert hast.

Ich muss erst mal eine neue Version erstellen, in der die Fehler behoben sind. Dann kann ich erst vergleichen, was beim Kompilieren und Re-Exportieren entsteht.
Bislang gab ja es nie Veranlassung, die TXT-Objekte nach dem Import/Export noch mal zu vergleichen, zumal ja nach dem Import ggf. durchaus reelle Fehler korrigiert werden müssen und sich die Versionen dadurch ohnehin unterscheiden. Das Standardverfahren ist das txt-Objektpaket importieren, in der Entwicklungsumgebung auf das Build vom Zielsystem wechseln, kompilieren und exportieren.

Im gesamten Merge war auch nicht ungewöhnliches, die Sprachlayer wurden vorher entfernt, damit nur noch ENU-Captions und damit die reellen Unterschiede übrigbleiben, dann wurde gemergt, und am Schluss die Sprachlayer wieder zugefügt. Das wird auch schon seit Jahren so gemacht, aussparen muss man da nur eigene Objekte, in denen Sonderzeichen außerhalb von Captions enthalten sind, weil daraus dann Fragezeichen werden können. Das sind aber alles bekannte Effekte möglicher Codeänderung durch den Compiler.

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

Ich habe gestern im Gesamtobjektpaket nach den Fehlerstellen gesucht, betroffen von diesem Effekt waren 4 Objekte in einem Paket von 409.
Ich habe nach der Korrektur durchgehend mit Build 37563 aus Update 10 ohne Löschen der Sprachlayer das Gesamtpaket importiert, kompiliert und exportiert und beide Txt-Objektdateien verglichen, die sind komplett identisch.

Das hat mit dem Mergevorgang von vor 14 Tagen aber leider nicht viel zu tun, da wurde bis zum letzten Kompiliervorgang mit Build 36897 aus Update 8 gearbeitet (erst dann auf Build 37221 gewechselt), außerdem mussten nach dem Einspielen des Merges des Grundpakets und dem Reimport der Sprachlayer ein Zusatzmodul noch aus einer anderen Datenbank geholt werden, außerdem einige nicht kompilierbare Objekte einzeln nachgemergt werden (dazu gehörten auch die obigen), doppelte Controls wegen Namenskonflikten aus Pages gelöscht werden usw., der ganz normale Mergealltag, aber alles manuell und alles schon hunderte Male durchexerziert.
Das einzige neue Schritt war, dass "Datenverlust durch Tabellenänderungen verhindern" schon beim Löschen der Sprachlayer ansprach und deswegen gleich ausgeschaltet wurde. Das wird beim lokalen Mergen von Vorlagendatenbanken aber immer abgeschaltet, wenn die nur zur Objektlieferung benötigt werden, spätetestes vor dem Objektimport des Mergeergebnisses, und war bislang nie ein Problem. Jedes monatliche Update wird genauso erstellt. Erst wenn eine bestimmte Vorlage dann getestet werden werden soll, wird nach Bedarf dafür eine Instanz erstellt.
Ein ruinierter Code wie der der obigen Beispiele kann dabei nur durch einen automatischen Prozess entstehen. Die einzigen Veränderungen in diesem Gesamtprozess, die ich da erkennen kann, sind die Unicodefähigkeit des R2-Clients, jetzt im Gegensatz zu NAV 2013 ja auch für die Captions, und die Verlagerung der Sync-Codes für C/AL von C/SIDE auf den SQL-Server, die wegen der Multi-Tenancy eingeführt wurde.
Auf jeden Fall kann man dem Compiler jetzt anscheinend nichts mehr glauben, denn alle vermüllten Objekte waren ja kompilierbar. Es bleibt also nur der Vergleich Vor-Import zu Nach-Export des Objektpakets.

Hallo,

ich habe das oder so ähnlich schon vor Jahren gesehen.

Bei mir hatte es Translate Export/Import zu tun.

Beispiel:
Translate Export für ein Objekte erstellen.
Im Code des Objekts einen String (mit Hochkommas) entfernen oder hinzufügen, z.b. MESSAGE('Hallo');
Translate Import machen und fertig ist der Salat. Das ganze kompiliert ohne Fehler.

ich habe das oder so ähnlich schon vor Jahren gesehen.

Bei mir hatte es Translate Export/Import zu tun.

Siehe auch hier: http://mibuso.com/blogs/zenandtheartofc ... ion-files/

Bei mir hatte es Translate Export/Import zu tun.

Siehe auch hier: http://mibuso.com/blogs/zenandtheartofc ... ion-files/

Vielen Dank, das ist eindeutig die Ursache. Ich hatte im Objektpaket zwar direkt DEU= zu DES= umgewandelt, aber ein paar zusätzliche bzw. geänderte Captions kamen auch über die Translatefunktion dazu und haben die Objekte dabei ruiniert. Da man durch das Refactoring von Codeunit 12 in R2 da ja nichts mehr mergen kann, wenn Module aus älteren Datenbanken entnommen werden müssen, ist es auch unvermeidbar, dass dort manuell Codezeilen mit Kommentaren eingefügt werden. Bei Bereitstellung von internationalen Datenbanken offensichtlich eine große potenzielle Fehlerquelle.
Schade, dass der Compiler den Code dermaßen durcheinanderwürfeln kann und die Funktionsbereiche nicht sauber trennt . Als Workaround kann man da wohl wirklich nur die Zeilen mit X1, X2… am Ende in der Translationdatei löschen, bevor man die importiert bzw. bei größeren Projekten nach einem Import in eine Puffertabelle hieraus eine so bereinigte ausgeben und diese dann importieren.

Hier noch eine andere Variation, wie selbstständige ungewollte Codeänderungen entstehen können, auch hier wieder im Zusammenhang mit Sprachlayerwandlung.
Statt

Code:

<> Wrong Expression

sollte da eigentlich lediglich

Code:

<> '')

stehen.

WrongExpression.png

Zumindest kommt dieser Fehler im Gegensatz zum obigen dann aber beim Kompilieren hoch. Teilweise wird auch nur ein Bruchteil "Wro" oder "W" davon eingefügt, wenn der Platz in der Zeile knapp ist.

Der Auslöser können anscheinend Feldnamenlängenänderungen sein, im meinem Fall wurde an dem Feld aber nichts geändert .
http://www.mibuso.com/forum/viewtopic.php?f=23&t=29947

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