NAV 2017 Extensions

AstiniaAstinia Posts: 37Member
Hello guru,

Does anyone have a real interaction with extensions on highly customized database? I have one Customer, who has 10 add-ons. Most of them are made as a regular ones (with old fashion fobs). Now we want to upgrade from 2009 to 2017 and we have several add-ons, coming in navx files.
This is good and nice and I'm excited about that. We have a lot of customazation on top of the add-ons. Will this all work for us?
In MSDN they go: "In most cases, two extension packages can coexist and work independently of each other; however there is the possibility that two apps will try to modify the same object properties. In those cases, if the conflict cannot be resolved, the installation of the conflicting extension fails." (from here

So, is there any who used several add-ons, provided as extensions? Let's say one page (Sales Order, let it be) have customazations with several extensions and changes from other add-ons (which I merged manually of course). Does it work correctly?
I don't really understand, if I publish an extension and then change the page - will it all work together? Or should I un-publish extension first?

If I have my database with changed objects with another add-on or another customazation and I want to install extension - will that work? Or will extension work only for 'plain' objects?

If I have extension for 'plain' NAV, but I have last hotfix in my database - will that work?

Does anyone have such an experience?

Thanks in advance!


  • neuroelectronicneuroelectronic Posts: 7Member
    edited 2017-06-16
    I can't imagine an extension that targets Sales Order would install smoothly on top of a customized Sales order page unless that customization is only implemented in new fields and the base fields haven't been modified by the customization. It may work anyway though. Since the extensions are generally black-box the only way to be sure is to test it, while being aware of how things are working in NAV and what you expect the extension to do.

    In this case, the extension developers will have to cooperate to have their extensions integrate well or move their customizations to non-base areas. That, or have the host extension create appropriate hooks (aka publisher functions) available for the dependent extension.

    Extensions may have to be updated with "hotfix" aka Cumulative Updates if the extension relies on the broken functionality, generally it would be rare that you would have to change your extension to support a hotfix, however.

  • AstiniaAstinia Posts: 37Member
    Thanks a lot for the reply. May be someone else has something to add as well?
  • neuroelectronicneuroelectronic Posts: 7Member
    edited 2017-06-20
    Can you be a little more clearer what you're asking for here? I'm not really sure what your question is. There's nothing inherently wrong with mixing modified code and extensions that would stop them from working together. It all comes down to what they're actually doing and if they mesh together.
  • DenSterDenSter Posts: 8,085Member
    Modifications for extensions are relative changes. In extensions v1 you have the DELTA files, and in v2 you have the extension objects. In both cases, things are added relative to an existing element. For instance, you add a field to a table, the DELTA file will have something in it that says "InsertAfter" and then it defines after which field the new field is added. This will work on any new version of that table object, as long the reference field still exists. So if your DELTA has a field added after the "E-Mail 2" field, your extension will not have a conflict as long as the "E-Mail 2" field is part of the reference table.

    You will need to test your extensions for each change to the base objects to make sure it still works. If a CU changes any of the reference points in your extension, you will need to create a new version of your extension.
Sign In or Register to comment.