[Gelöst] Symbol Download bei technischem Update auf BC 14

Hallo zusammen,

derzeit probiere ich ein technisches Update von NAV 2016 auf Business Central 14 (OnPrem) hinzubekommen. Die Konvertierung der Datenbank funktionierte auch. Win- und DevClient lassen sich ebenfalls problemlos öffnen. Sync-NAVTenant geht auch.

Das Problem:
In VS Code konnte ich bisher keine Symbole herunterladen.

Wie auch? Die Anwendung ist immer noch inhaltlich auf NAV 2016. Es gibt allerdings eine Möglichkeit, die Symbole manuell zu erzeugen. Hierfür stellt die finsql.exe den Programmparameter generatesymbolreference bereit. Bei gestoppter ServiceTier habe ich erfolgreich Symbole in der Tabelle „Object Metadata“ erstellen können. Hierzu musste ich cmd als Administrator starten und für meine Datenbank folgendes Kommando eingeben:
finsql.exe Command=generatesymbolreference, Database="MyDatabase", Servername=MyComputerName\SQL2014
Nach Abschluss der Verarbeitung habe ich auch eine „navcommandresult.txt“ Datei erhalten, die finsql.exe in dem Verzeichnis abgelegt hat, in dem finsql.exe selbst steht. Inhalt:

[0] [23.09.19 14:26:18] Der Befehl wurde in '364' Sekunden erfolgreich abgeschlossen.

Wie ihr seht, hatte ich das bereits gestern hinbekommen. Soweit, so gut...

Allerdings erhalte ich nun beim Herunterladen von Symbolen in VS Code immer noch folgende Meldung:

[2019-09-24 08:58:28.79] Sending request to http://127.0.0.1:7235/BC14-35916-A/dev/ ... t=13.0.0.0
[2019-09-24 08:58:28.83] The request for path /BC14-35916-A/dev/packages?publisher=Microsoft&appName=Application&versionText=13.0.0.0 failed with code ServiceUnavailable. Reason: Auf den Tenant 'default' kann nicht zugegriffen werden.
[2019-09-24 08:58:28.83] The request for path /BC14-35916-A/dev/packages?publisher=Microsoft&appName=System&versionText=13.0.0.0 failed with code ServiceUnavailable. Reason: Auf den Tenant 'default' kann nicht zugegriffen werden.
[2019-09-24 08:58:28.83] Could not download reference symbols. Please ensure that:
1. The correct server name and instance are specified in the launch.json file.
2. The correct application version is specified in the app.json file.
3. The dependencies are correctly specified in the app.json file.

Ich habe gedacht, dass es vielleicht an der Versionsnummer liegt. Im Beispiel hatte ich es mit „13.0.0.0“ ausprobiert, weil es mit „14.0.0.0“ nicht ging und ich mit 13 schon mal irgendwann anders Erfolg hatte.

Nun - es läuft alles, bis auf den Symbol Download. Die ServiceTier hatte ich natürlich zwischenzeitlich wieder eingeschaltet. Zuletzt habe ich über das SQL Management Studio für die betreffende Tabelle folgendes Select-Statement abgesetzt:

select * from [Object Metadata];

Das Ergebnis liefert für alle Datensätze als „Metadata Version“ die Version „130000“. Damit gehe ich mal davon aus, dass ich in AL die Versionsnummer „13.0.0.0“ verwenden muss. Auch im Feld „Symbol Reference“ steht für jeden Datensatz etwas drin. Ich habe also tatsächlich Symbole, die ich leider nur nicht in VS Code laden kann. Es sind irgendwelche Hexadezimalzeichenfolgen, die mit „0x“ anfangen und dann mit einem ganzen Haufen von aneinandergereihten Hex-Werten fortgesetzt werden.

Nun stehe ich immer noch vor der Frage, wie ich sie in VS Code laden kann. Ich hoffe jemand von Euch hat diesbezüglich schon einmal mehr Erfolg gehabt, als ich.

Viele Grüße
Marc

Zuletzt geändert von TSO_MB am 4. Oktober 2019 09:15, insgesamt 1-mal geändert.

Auf den Tenant 'default' kann nicht zugegriffen werden.

Ist der Developer Service Endpoint am Server korrekt aktiviert?
https://github.com/microsoft/AL/issues/5122
Wurden die System Symbols der DVD installiert?
https://docs.microsoft.com/en-us/dynami ... extensions

Hallo Kai,

erst einmal vielen Dank für Deine Antwort.

Folgende Einstellungen hat die betroffene ServiceTier:
„Enable Developer Service Endpoint“ ist angehakt
„Enable loading application symbol references at startup“ ist angehakt
„Allowed Extension Target Level“ ist Internal

Eine ganz wichtige Sache steht ja in dem von Dir verlinkten Beitrag:

Further did you published the System App from the product DVD?

Es gibt ja keine für NAV 2016 und die für BC14 dürften nicht zur Applikation passen. Kann ich das trotzdem irgendwie als Datei extrahieren und veröffentlichen, so dass VS Code darauf Zugriff hat?

Der Developer Endpoint Port „7235“ war auch schon in meiner „launch.json“ eingetragen. Hier die gesamte Datei 1 zu 1 wie sie aktuell ist:

{
"version": "0.2.0",
"configurations": [
{
"type": "al",
"request": "launch",
"name": "Your own server",
"server": "http://127.0.0.1:7235",
// "port": 7235,
"serverInstance": "BC14-35916-A",
"authentication": "Windows",
"startupObjectId": 22,
"startupObjectType": "Page",
"breakOnError": true,
"launchBrowser": true
}
]
}

Ich habe den Port direkt hinter dem Server angegeben. Vorher hatte ich es auch mal nur mit „127.0.0.1“ ohne Portangabe dahinter und der „port“-Eigenschaft (jetzt auskommentiert) probiert. Das gab den Fehler:

Reason: No published package matches the provided arguments.

So wie die „launch.json“ jetzt ist, dürfte es also richtiger sein.

Gruß,
Marc

So wie die „launch.json“ jetzt ist, dürfte es also richtiger sein.

Nein, mit separater Portnummer ist es eigentlich richtiger .
https://www.kauffmann.nl/2017/12/07/how ... -nav-2018/

Nun... das haben wohl inzwischen so viele Leute falsch gemacht, dass Microsoft das Verhalten für BC14 mittlerweile geändert hat.
In meinem Test gerade konnte ich im "OUTPUT" feststellen, dass für beide Varianten der richtige Port verwendet wird. Nur wenn ich den Port weder per Doppelpunkt noch über die Port-Eigenschaft angebe, wird Port 7049 verwendet.

Die Fehlermeldung ist jetzt überigens

No published package matches the provided arguments.

Das Problem mit dem default Tenant habe ich - warum auch immer - in beiden Varianten nicht mehr. Die neue Fehlermeldung macht auch Sinn. Ich habe schließlich nichts bereitgestellt. Auch Get-NAVAppInfo bringt daher erwartungsgemäß keine Ergebnisse. Kann ich denn einfach die Symbole von der BC14 Produkt DVD verwenden? Ich befürchte, dass das nicht passen kann, denn die zugrundeliegende Datenbank ist doch noch NAV 2016 (= nur technisches Update).

Hi,

habe ich das richtig verstanden, dass du die DB nur konvertiert hast? Nichts weiter? keine frischen Objekte eingespielt und die Clients sind lauffähig?
Du hast also noch die alten NAV 2016er Objekte drin?

Meine (sicherlich echt blöde) Frage: was willst du damit?

Du brauchst natürlich die system.app und zwar die aus der 14er - eine andere hast du ja garnicht zur Verfügung - aber das nützt dir auch nicht viel, wenn du noch auf die alten NAV-Objekte aus 2016 zugreifst.

Warum hast du die DB nicht "ordnungsgemäß" konvertiert?

Hallo,

ja das hast Du richtig verstanden: Es ist nur eine technische Umstellung (inhaltlich NAV2016) und die Clients sind lauffähig. Getestet haben wir die Funktionalität noch nicht. Aber auf den ersten Blick sieht das mit dem Windows Client ganz gut aus. Der WebClient findet natürlich erwartungsgemäß nichts, lässt sich aber erst einmal auch ohne zu meckern starten.

Du brauchst natürlich die system.app und zwar die aus der 14er - eine andere hast du ja garnicht zur Verfügung - aber das nützt dir auch nicht viel, wenn du noch auf die alten NAV-Objekte aus 2016 zugreifst.

Meine Herangehensweise war daher, selbst passende Symbols zu erzeugen und anschließend irgendwie darauf mit VS Code zuzugreifen. Ob das überhaupt geht... keine Ahnung. Ich habe im Moment leider keine Idee wie ein Zugriff auf die Symbole gelingen könnte. Unter SQL sieht es jedenfalls erst einmal so aus, als wenn sie da sind. Warum sollte es also nicht gehen? So habe ich die Hoffnung, dass vielleicht hier im Forum jemand schon mal erfolgreich so etwas Ähnliches durchgeführt hat.

Was das werden soll?
Es geht um eine individuelle HR Lösung, die auf dem NAV Personalwesen Standard basiert (52xx). Ziel ist es, vorab schon einmal möglichst gekapselte AL Extensions zu entwickeln und für diese Lösung als Erweiterung nutzen zu können, ohne gleich den Aufwand einer kompletten inhaltlichen Migration auf BC zu haben. Die Erweiterung würde die Grundanwendung kaum berühren. Ich wollte aber dennoch nicht unbedingt mit RecordRef arbeiten. Daher wäre es sinnvoll, irgendwie an die Symbole ranzukommen. Ich gehe mal davon aus, dass diese Datenbank künftig durchaus „ordnungsgemäß“ auf BC hochgezogen werden soll. Aus zeitlichen Gründen wurde vorerst dieser Weg gewählt.

(Kurze Info:
Ich bin morgen den ganzen Tag unterwegs und werde wahrscheinlich vor übermorgen nicht antworten können.)

Gruß,
Marc

Vielen Dank für Eure Unterstützung bisher in diesem Fall. Inzwischen haben wir zu diesem Fall einen Microsoft Support Case eröffnet. Microsoft sagt hier eindeutig, dass ein rein technisches Upgrade auf Business Central nicht unterstützt wird. Als Grund werden die tiefgreifenden Veränderungen hinsichtlich Codeunit 1 angeführt. Eine rein technische Umstellung steht damit überhaupt nicht mehr zur Diskussion und funktioniert auch nicht. Ich stelle den Fall hier auf „gelöst“.

hi, danke für deine Rückmeldung.
gerade was die Codeunit-Thematik anbetrifft, hatte ich mich nämlich gewundert, dass der Client bei euch lauffähig ist ;)