AX7 – Code-Konflikte auflösen beim Versionsmerge

Wenn man auf das neue Microsoft Dynamixs AX aktualisiert oder auch nur ein Code Upgrade auf eine neuere Version von AX7 durchführt, ist es äußerst wahrscheinlich, dass man Code-Konflikte (auf-) lösen muss. Im Folgenden findest du einen möglichen Weg, die Merge-Arbeit aufzuteilen und auszuführen.

Work Items

Der Code Upgrade Service hat eine Liste von Work Items in VSTS (Visual Studio Team Services) erstellt. Pro Konflikt gibt es dort einen Task, wobei sich nicht alle Tasks auf Code-Konflikte beziehen. Ich empfehle, diese Liste dazu zu verwenden, die zu vollbringende Arbeit aufzuteilen. Wir verwenden dabei ein Pull-System, bei dem sich jeder einfach den nächsten freien Task nimmt und sich diesen zuweist sowie den Status auf In Progress setzt.

Konflikte sichten und lösen

Man könnte auch die Visual Studio Solutions, die vom Code Upgrade Service erstellt wurden, als Ausgangspunkt nehmen. Diese befinden sich im Verzeichnis Projects des erstellten Branch.
Wir benutzen diese allerdings nicht… In aller Regel kopiere ich einfach den Namen des Objekts, das ich bearbeiten möchte, aus der Überschrift des Tasks in den Filterbereich des Application Explorer.

Anschließend kann man das Objekt in ein Projekt im Solution Explorer manövrieren (Drag and Drop) oder sogar direkt mit der Bearbeitung beginnen. Nachdem wir es mit einem Konflikt zu tun haben, steht ja schon fest, dass es sich in einem modifizierten Zustand in einem Custom Model befindet und damit sollte das passen. Nach meinem Geschmack ist es jedoch empfehlenswert, immer den Weg über ein Projekt (das ja immer zu genau einem Model gehört) zu gehen, um dadurch Klarheit im Vorgehen sicherzustellen.
Um einen Konflikt auflösen zu können, muss man das Objekt in der Designer-Ansicht geöffnet haben (und nicht in der Code-Ansicht). Befindet man sich bereits in der Sicht auf den Code, so ist es am einfachsten, irgendwo im Code einen Rechtsklick zu vollführen, um anschließend Open Designer auszuwählen. Man trifft im Fall von Klassen öfter auf diese Situation, weil diese – im Gegensatz zu allen anderen Objekttypen – standardmäßig in der Code-Ansicht geöffnet werden, wenn man sie im Solution Explorer doppelklickt.

Man sieht einem Objekt sowohl im Solution Explorer als auch in der Überschriftszeile der Designer-Ansicht an, dass es einen oder mehrere Konflikte darin gibt – der Name des Objekts ist dann durch [!] erweitert.
Bei Objekten mit Konflikten kann man in der Designer-Ansicht ganz einfach auf eine Sicht mit nur den Konflikten filtern, indem man cf: im Suchfeld (Search …) eingibt.
Um einen einzelnen Konflikt aufzulösen (man muss diese auch einzeln bearbeiten, wenn es mehrere innerhalb eines Objekts gibt), macht man einfach einen Rechtsklick auf den Konfliktknoten (diese sind mit einem Symbol bestehend aus zwei roten aufeinander zeigenden Pfeilen markiert) und wählt Resolve code conflicts ….

In der Folge öffnet sich ein Three-Way-Merge, bei dem der neue Standard-Code auf der linken Seite, der alte, modifizierte Code auf der rechten Seite und das Ergebnis des Merge unten zu sehen sind. Grün hinterlegter Code ist dabei schon automatisch zusammengeführt worden, wohingegen orange hinterlegter manuell gelöst werden muss. Man kann den Code links und / oder rechts übernehmen, indem man die jeweils links davon befindlichen Checkbox bedient. Die Reihenfolge wird im Ergebnis entsprechend berücksichtigt. Man kann im resultierenden Code auch direkte Eingaben machen.

Verlässt man diese Ansicht oder speichert das Objekt (Ctrl+S), erscheint eine Sicherheitsabfrage, ob der Konflikt auch gelöst sei. Bestätigt man dies, verschwindet das Konflikt-Symbol (rote Pfeile). Wenn alle Konflikte eines Objekts aufgelöst und das Objekt gespeichert wurde, verschwindet auch das Ausrufezeichen in den eckigen Klammern – es gibt keine offenen Konflikte mehr.

Customization entfernen

Im Beispiel, das man in den Screenshots nachverfolgen kann, kam es sogar zu einer Situation, in der das Objekt gar keiner Modifikation mehr bedurfte und entsprechend aus dem Custom Model gelöscht werden konnte. Dazu muss man es im Solution Explorer aus dem entsprechenden Projekt mit Delete löschen. Aus Sicht der Versionskontrolle entsteht dann dabei entsprechend ein Pending Delete (statt des Pending Change davor).