Bugs im automatischen Merge

Beim Ausprobieren der neuen automatischen Mergefunktionen mittels der PowerShell-Cmdlets bin ich auf diese Bugs gestoßen.
Das Schlimme ist: Diese Addon-Objekte (nicht im NAV-Standardbereich, es gab also gar nichts zu mergen) sollten eigentlich im Gesamtprozess nur "durchgereicht" werden. Trotzdem wurden sie verändert.
Bei eckigen Klammern bei Verwendung von Arrays in Reports/Pages werden links eine und rechts zwei eckige Klammern "dazugedichtet".
Links Ergebnis vom automatischen Merge, rechts korrekte Version

MergeArrayfehler.png

Mit Umlauten kann das Tool leider nicht umgehen:
Die Textkonstante mit "ä" wird in Anführungszeichen eingeschlossen:

MergeBugTextkonstante.png

In C/AL kann man (leider, sollte man vermeiden) Umlaute auch in Variablennamen verwenden, das MergeSplit-Cmdlet schließt diese Variablen in der Variablenliste (aber nicht im Code) dann auch in Anführungszeichen ein.

GeänderteVariable.png

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

Hallo Kai,

Kannst du diese Fehler bitte offiziell bei uns melden?

Danke!

Hallo Kai,

Kannst du diese Fehler bitte offiziell bei uns melden?

Danke!

Am Besten beides, also hier schreiben und Fehler melden.
Das zu wissen ist für die Community schon hilfreich.

mfg,
winfy

Hallo,

autsch. Danke, sollte man wissen. Ich habe mich gefragt wofür man diese neuen cmdlets wirklich braucht... also jetzt mal im tatsächlichen, täglichen Einsatz. Für die Aktualisierung einer Standarddatenbank braucht man es anscheinend nicht , und praktisch alle Kundendatenbanken haben AddOn-Objekte. Da hat man dann schon mal Glück wenn man die alle als Text exportieren kann... also wenn man nicht die Microsoft W1-ich-darf-alles Lizenz hat, sondern eine normale Partnerlizenz. Das kann man ggf. noch umschiffen. Irgendwie bekommt man die wichtigen Objekte als .txt raus. Dann möchte ich ein AddOn (was ja auch auf einer Basisversion lebt) auf eine neuere Version heben oder in eine Kundendatenbank einmergen. Oder nur ein Update davon, z.B. OPPlus 7.05 (derzeit 7.03.04 in der Kundendatenbank drin). Mal abgesehen davon, dass auch die Updates wieder auf einer anderen Basisversion als meine Kundendatenbank ist oder sein kann (mit den RollUps/Cumulative Updates ist die Wahrscheinlichkeit nahe 1), muss ich meine Mergeaktionen so aufteilen, dass ich immer aus 3 Basisdateien eine vierte erzeuge, dann die Konflikte auflösen, mit einem Mergeprogramm meiner Wahl, das Ergebnis in eine NAV-Datenbank einlesen, schauen ob die Syntax korrekt ist, wieder auslesen, weiter gehts, bis ich die Objekte in der Kundendatenbank habe. Das ist so ähnlich (ich würde sagen nicht ganz so effektiv) wie ich bis Anfang 2013 mit Subversion (TortoiseSVN), NavObjectSplitter (danke, Carsten :), einigen cmd-Dateien und FreeCommander gearbeitet habe und auf Arbeit immer noch mache. Nur das der Merge sowieso von Subversion bereitgestellt wird. Die kennen keine NAV Objektsyntax, das ist aber auch alles. Die Problematik mit den Control IDs, Versionsstrings, Kommentarsektionen und Sprachschichten hat man da gefühlt ertmal genauso wie mit den cmdlets. Als ich das Whitepaper zu den cmdlets gelesen habe dachte ich mir: Ja iss schon cool wenn die die Syntax kennen und das richtig herum zusammenbauen. Aber wirklich Konflikte lösen geht damit auch nicht, und der Merge macht immer nur einen 3seiten-Merge, die ganze Changeset-Historie haben sie ja nicht. Da muss man dann wie bisher ran.
Deutlich effektiver wirds mit sowas wie Mercurial als Versionskontrollsystem, ist zumindest meine Erfahrung. Ringsrum ists praktisch das gleiche, aber die Mergefunktion kann zwischen verschiedenen Zweigen hin und her mergen... und das mit keinen größeren Problemen als oben beschrieben, das aber ohne die bei SVN nötigen Zwischenversionen. Händische Nacharbeit ist leider immer erforderlich. Und das man die Syntax halt kennt.
Was toll wäre: ein TortoiseMerge (oder meinetwegen ein kdiff3) was die NAV-Syntax kann. Und zusätzlich eine Funktion die das ersetzen von Versionskürzeln in den Versionsstrings regelt, mit Datumsregel, und noch ein paar andere Kleinigkeiten. Und ein Textdatei-Syntaxchecker. Das würde gut weiterhelfen :)

LG Jens

Hier noch das Szenario (wie im White Paper auf Seite 4)
Im ORIGINAL: Alle 4214 NAV 2013 R2 Standardobjekte auf Basis Cumulative Update 8
Im MODIFIED: Alle 4214 NAV 2013 R2 Standardobjekte auf Basis Cumulative Update 9
Im TARGET: 400 NAV 2013 R2 Addon-Objekte (teilweise Standardobjekte) auf Basis Cumulative Update 8
Im RESULT sollen dann 400 Addon-Objekte auf Basis Cumulative Update 9 entstehen.

Der Ordner RESULT\ConflictTarget ist nach dem Mergevorgang leer, laut Cmdlet liegen also keine Konflikte mit den Addon-Objekten vor. Das ist auch korrekt, denn bis auf die Versionsliste, Datum und die obigen Fehler wurde sonst alles richtig gemergt. Der Fehler mit den eckigen Klammern tritt dabei z.B. auch in Report 117 auf, alle Reports und Pages sind betroffen.

MergeFehlerReport117.png

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

Update dazu:
Der "Übeltäter" ist nicht das Merge-Cmdlet, sondern das Split-Cmdlet. Ich habe den Titel deswegen angepasst.
Ein normaler direkter Mergeprozess erfolgt über diese Cmdlets: 1.Split 2.Merge 3.Join, wobei für 1. und 3. auch andere Tools verfügbar sind.
Die schlechte Nachricht: In NAV 2015 kommen ja diverse Erweiterungen in dem Bereich, aber behoben sind diese Fehler nicht.
Die gute Nachricht: Die Importroutine entfernt die überzähligen Zeichen wieder, innerhalb der geöffneten NAV-Objekte sieht es dann wieder korrekt aus.
Bei manuellen Vergleichen (um das Ergebnis vom Mergevorgang zu verifizieren), ist es trotzdem natürlich sehr nervig, wenn sinnlose Unterschiede ausgewiesen werden.

In NAV 2015 kommen ja diverse Erweiterungen in dem Bereich, aber behoben sind diese Fehler nicht.

Aber wohl bald, siehe Beiträge von Morten Jensen von MS hier :
http://blogs.msdn.com/b/nav/archive/201 ... -2015.aspx

Die merkwürdige Verlangsamung des Split-Cmdlets zum Schluss, die ich bei mir auch immer habe und schon kurz nach Erscheinen im Blog kommentiert habe, ist wohl etwas mysteriöser, weil diese nicht auf jedem System auftritt. Bei der Directions kam sie dann aber lt. Morten Jensen in einem Workshop auch hoch. Wo da der Flaschenhals sitzt, ist noch unklar.

Im Cumulative Update im Dezember sollen die Hotfixes für die Cmdlets erscheinen (wegen []-Arraybugs, Performanceeinbrüchen usw.)
Quelle:
http://blogs.msdn.com/b/nav/archive/2014/10/03/merging-application-objects-using-windows-powershell-in-microsoft-dynamics-nav-2015.aspx?PageIndex=2#comments

Im Cumulative Update im Dezember sollen die Hotfixes für die Cmdlets erscheinen (wegen []-Arraybugs, Performanceeinbrüchen usw.)

Bis auf den kleinen Bug mit den einschließenden Anführungszeichen bei Sonderzeichen in Variablen und Reportlabels nach dem Splitten sind die Fehler in Cumulative Update 2 behoben.

There is another critical issue with the merge cmdlets. Please see this entry for another issue:
https://grumpynav.wordpress.com/2015/01 ... correctly/

Sollte es jemand gestört haben, in NAV 2015 Cumulative Update 8 ist folgendes behoben:

372070 The DotNet variable property, SuppressDispose, is not supported by the Application Merge Utilities powershell commands.
372300 Local variables are missing after merge.

Ob es an Windows 10 oder der dazugehörigen aktuellen PowerShell 5 (oder beidem) liegt, ist unklar, auf jeden Fall arbeiten die Cmdlets dort nicht mehr richtig (getestet mit den aktuellen Tools aus NAV 2015 Cumulative Update 10).
Ich habe eben ein Objektpaket zerlegt, und in allen Pages endet der Code in Zeile 11 nach CaptionML=[.

Code:

OBJECT Page 36 Assembly BOM
{
  OBJECT-PROPERTIES
  {
    Date=07.09.12;
    Time=12:00:00;
    Version List=NAVW17.00;
  }
  PROPERTIES
  {
    CaptionML=[

.
Auch andere Cmdlets wie Remove-NAVApplicationObjectLanguage funktionieren nicht:

WARNUNG: UnhandledErrorMessage
Remove-NAVApplicationObjectLanguage : Der Typeninitialisierer für
"Microsoft.Dynamics.Nav.Model.TypeSystem.WindowsLanguageHelper" hat eine Ausnahme verursacht.
In Zeile:1 Zeichen:1
+ Remove-NAVApplicationObjectLanguage -Destination TEST -Source t1.txt
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Remove-NAVApplicationObjectLanguage], TypeInitializationException
+ FullyQualifiedErrorId : System.TypeInitializationException,Microsoft.Dynamics.Nav.Model.Tools.Cmdlets.RemoveNavAppli
cationObjectLanguage.

Ob es an Windows 10 oder der dazugehörigen aktuellen PowerShell 5 (oder beidem) liegt, ist unklar, auf jeden Fall arbeiten die Cmdlets dort nicht mehr richtig (getestet mit den aktuellen Tools aus NAV 2015 Cumulative Update 10).

Erst mit den kommenden Updates im Oktober sollen die Versionen NAV 2013, NAV 2013 R2 und NAV 2015 Windows 10-Kompatibel sein:
Windows 10 and Dynamics NAV

Die aktuelle Version der NAV 2016-Cmdlets (aus dem 90er-Programmverzeichnis) produziert Fehlmerges, zumindest unter Windows 10.
Bei den monatlichen Routinemerges für eine NAV 2013 R2 wurden z.B. aus Tabelle 120 und 122 unsere Addon-Felder rausgelöscht.
Ich habe dann den kompletten Vorgang mit den aktuellen Cmdlets von NAV 2015 wiederholt, dort trat der Fehler nicht auf.

Links Fehlmerge mit NAV 2016-Cmdlets, rechts korrekt inklusive der Addon-Felder mit NAV 2015-Cmdlets.

Mergefehler.png

Außerdem wurde (in NAV 2016) z.B. Codeunit 13 mit den aktuell 2 hinzugekommenen Zeilen völlig falsch gemergt, in dem TARGET-Codeblock fehlte unser Addon-Code gänzlich.

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

Thema verschoben von NAV 2013 nach NAV 2016.

Edit: Beitrag von hier verschoben (Kowa)

Achtung: Enthält eurer Code geschweifte Klammern {} zum Auskommentieren von Code, wird das vom cmdlet einfach ignoriert.
Das Merge-Ergebnis ist dann nicht nur falsch, ihr werdet auch nicht gewarnt. Microsoft gedenkt aktuell noch nicht, dieses Verhalten zu verbessern - es wird nicht als Fehler anerkannt.

Lest hier mehr dazu: Caution! The merge cmdlets might merge incorrectly!

Bugfix für NAV 2016-Cmdlets in Cumulative Update 7

Merge cmdlet indicate conflicts but no conflicts are shown.