To build or not to build

Dass die technischen Versionen von Client und Server zusammenpassen sollten, war ja schon immer so, aber mitterweile reichen kleine Unterschiede in den Buildversionen für große Konflikte.
Anbei ein Beispiel, was passiert, wenn ein Build des Windowsclients und der Entwicklungsumgebung nicht zusammenpassen (in diesem Fall NAV 2013 R2 RTM Build 35473 "gegen" Entwicklungssystem mit Build 35800 aus Update Rollup 2)

Das Anmelden an der Datenbank lief erst mal noch normal, buchen war möglich. Noch haben ja alle Objekte technischen Build 35473 .

Dann eine belanglose Änderung an Codeunit 12, kompiliert mit Build 35800. Der nächste Buchungsversuch brach mit dieser Fehlermeldung ab:

dllerror_codeunit12.png

Nach Kompilieren aller Objekte mit Build 35800 startete der Windowsclient dann gar nicht mehr und brach sofort mit Fehlermeldung ab:

dllerror_codeunit5150.png

Beim Verwenden des Windowsclients mit Build 35800 ging dann alles wieder. Das ist in der Praxis natürlich nicht immer so einfach machbar wie auf dem eigenen Testsystem, also immer darauf achten, dass die Builds übereinstimmen.
Tag: does not contain a constructor that takes 5 arguments

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

Aber immerhin ist die Fehlermeldung recht eindeutig

Heisst das, dass auch alle Zielsysteme bei den Kunden mit demselben Build laufen müssen, wie die eigene lokale Entwicklungsumgebung?

Heisst das, dass auch alle Zielsysteme bei den Kunden mit demselben Build laufen müssen, wie die eigene lokale Entwicklungsumgebung?

Genauso klingt es zumindest. Bin mal gespannt wie das weitergeht.

LG Jens

Heisst das, dass auch alle Zielsysteme bei den Kunden mit demselben Build laufen müssen, wie die eigene lokale Entwicklungsumgebung?

Nicht immer, aber immer öfter .
Manche Builds vertragen sich im Bezug auf das Kompilieren, andere untereinander nicht. Wenn das höhere Build Fehler behebt, geht es meist gut, wenn es neue Funktionalität bringt, dann meist nicht. Es ist dem Build ja auch nicht anzusehen, welche Änderungen es bringt, wenn man nicht die gesamte Histore studiert, und auch dann ist man nicht vor Überraschungen sicher. Das kann NAV-intern sein (so wie oben), Anbindung zum SQL-Server, Schnittstellen zu externen Programmen, Änderungen im Web- oder Sharepointclient usw.
Deswegen sollte man die Objekte zumindest testweise beim Entwickeln mit dem Build des Zielsystems kompilieren, damit es dort keine unangenehmen Überraschungen gibt, auch wenn man dieses Build bei der Entwicklung sonst nicht nutzt. Wenn bei dem Hotfix steht "You may have to compile the objects in your database after you apply this hotfix" ist es ohnehin angebracht, das auch durchzuziehen.
Da ja mittlerweile wöchentlich technische Builds erscheinen und monatliche Applikationsbuilds in Form der Update Rollups bzw. Cumulative Updates, ist es völlig illlusorisch, jede Kombination im laufenden Betrieb parat zu haben, es sei denn, man hat nur einen sehr kleinen Kundenstamm zu betreuen.

Danke für die Antwort, Kai.

Wenn ich das richtig verstehe kann ich in der Regel auf einem höheren Build entwickeln und die Objekte bei Kunden mit einem tieferen Build einlesen, sollte diese dort aber immer nach dem Import kompilieren. Das wäre ja durchaus zu handeln.

Ist das nur für 2013 ein Thema oder greift es auch bei der 2009er Version ?

Ist das nur für 2013 ein Thema oder greift es auch bei der 2009er Version ?

Prinzipiell gilt das für alle Versionen, aber früher war das eher eine Randerscheinung, weil meist nur dann das Build gewechselt wurde, wenn das alte Probleme machte.
Das war auch immer die offizielle Aussage von MS dazu, dass man das nur installieren sollte, wenn man von dem bestimmten Problem betroffen war.
Dadurch, dass jetzt seit NAV 2013 im festen Rhythmus Platform oder Application Builds erscheinen, werden bei den Installationen meist die gerade aktuell verfügbaren verwendet. Somit muss diese Abstimmungsproblematik viel mehr beachtet werden als früher.

Wenn ich das richtig verstehe kann ich in der Regel auf einem höheren Build entwickeln und die Objekte bei Kunden mit einem tieferen Build einlesen, sollte diese dort aber immer nach dem Import kompilieren.

Kompilieren sollte man auf dem Zielsystem sowieso immer noch einmal, aber in so einem Fall würde ich einen extra Ordner im Progammverzeichnis erstellen mit 70_<Buildnummer>, dort alles mit dem gleichen Build versorgen wie beim Kunden vor Ort, und nach Abschluss der Entwicklung daraus die finsql.exe starten und damit kompilieren. Alternativ eventuell nur noch TXT-Fobs ausliefern, je nach Situation vor Ort, wenn man sicher ist, dass diese dort auch zuverlässig verarbeitet werden und auch können (geht nicht immer, je nach Bediener, Lizenz und Objektnr.) und nicht manipuliert werden. Dann besteht zumindest keine Gefahr, dass das kompilieren vergessen wird. Ich liefere normalerweise ohnehin immer beides aus, also alle Objekte kompiliert und unkompiliert (wenn es an andere MBSPs geht). Da ab NAV 2013 im Gegensatz zu früher beim Abbruch von TXT-Fobimporten die bereits importieren Objekte dann unkompiliert in der Datenbank sind, muss dass immer vorab in einem Testsystem verifiziert werden. Aber das machen ja sowieso alle, oder ?

Zu dem Verhalten bei abweichenden Builds zwischen und Server und Clients gibt es ab NAV 2015 CU 2 bzw. NAV 2013 R2 CU14 eine zusätzliche Servereinstellung ClientBuildRestriction: Introducing a build version check between NST and Windows and Web clients