NAV Development Preview – November Update

 

Welcome to yet another update for the Developer Preview, we’re now introducing the November update. As usual, we’ve fixed a lot of issues reported by you, for more information view the list of fixed issues, In addition to that we’re announcing the following changes as you can see listed below. To jump directly to an updated image go to the Azure Gallery sign up at http://aka.ms/navdeveloperpreview.

Application dependency 

It is no longer necessary to specify application locale in app.json. Your AL package will be compiled against the application that is present on the server that you connect to. This allows you to write a single AL extension for multiple country versions as long as you don’t depend on country-specific code. If you do depend on country-specific code you should only try to compile your app against a server set up for that country.

The application property in app.json has changed its format accordingly.

Old syntax:

“application”: { 

    “version”: “11.0.0.0”, 

        ”locale”: “W1” 

} 

New simple syntax:

“application”: “11.0.0.0” 

This new approach allows you to submit a single app to AppSource that works with multiple country application databases as long as the base application code is compatible with your extension code.

Runtime packages 

For distribution extensions it is now possible to generate “Runtime” packages that do not contain any AL code, but instead the compiled files that the server uses.  

First, you must have an extension developed and published to an on-premise instance. Then, for generating the package, connect to the server and find the extension by using the following powershell command: 

  Get-NavAppRuntimePackage 

To publish and install the package, use the following powershell commands: 

  Publish-NavApp 

  Install-NavApp 

Please note that this has the limitation that it only works for on-premise installations; the debugging experience is very limited since no source code is available and it cannot be used for submissions to AppSource. 

 

Translations     

We have improved the translation feature to include support for XLIFF files. To enable it, open your app.json file and add the following: 

  “features”: “TranslationFile” 

Then, invoke the package command (Ctrl+Shift+B) in Visual Studio Code and you will get a /Translations folder with the .xlf files ready to be translated. The generated .xlf file can be used in many of the free or commercial tools for translators. All labels, label properties (Caption, Tooltip etc.), and report labels will be included in the .xlf file and be ready for translation. 

When you have specified the target language and translated your labels, include the renamed .xlf file in the /Translations folder. Make sure that the name is not the same as the file which is being generated as it will be overwritten.  

When publishing your extension the next time, it will be translated to your language of choice. 

There are a few things to note: the ML properties (CaptionML, TooltipML etc.), the old report label syntax, and TextConst do not get included in the .xliff file and will not be translated. Make sure to update your code from the old ML syntax (=ENU=’asd’;DEU=’qwe’) to the new label syntax described below. 

The label syntax, in this example for the Caption property, is the following: 

Caption = ‘Developer translation for %1’,  Comment = ‘%1 is extension name’, locked = false, MaxLength=999; 

The comment, locked, and maxLength attributes are optional and the order is not enforced. 

Use the same syntax for report labels  

labels
  {
        LabelName = ’Label Text’, Comment=’Foo’, MaxLength=999, Locked=true;
  } 

And label data types:

var
    a : Label ’Label Text’, Comment=’Foo’, MaxLength=999, Locked=true; 

Please note that you can use the new translation files approach only for objects from your extension. For translating the base application you still need to use the .TXT files.

For more information, see the documentation.

Running C/SIDE and AL side-by-side

We’ve implemented support for development using both C/SIDE and AL, as well as the in-client designer side-by-side. When new objects are added or changed in C/SIDE these changes must be reflected in the symbol download in Visual Studio Code using the AL Language extension. To enable this, new commands and arguments have been added to finsql.exe. For more information about running C/SIDE and AL side-by-side see the documentation.

As usual we encourage you to let us know how you like working with these additions and keep submitting suggestions and bugs. You can see all the filed bugs on our GitHub issues list (https://github.com/Microsoft/AL/issues). To get an updated image jump directly to the Azure Gallery signup at http://aka.ms/navdeveloperpreview.

For a list of our previous blog posts, see the links at the end of this post.

/NAV

Our earlier blog posts:

NAV Development Tools Preview – October Update

NAV Development Tools Preview – September Update

NAV Development Tools Preview – August Update

NAV Development Tools Preview – July Update

NAV Development Tools Preview – June Update

NAV Development Tools Preview – April Update

NAV Development Tools Preview – March Update

NAV Development Tools Preview – February Update

NAV Development Tools Preview – January Update

Announcing the Preview of Modern Development Tools for Dynamics NAV