Unpacking NAV App Package OR Unpack an Extension in Dynamics NAV 2016 - Tips, Tricks & Facts #4

Hi guys,

Let's take a scenario where an extension named 'My_Location_Extension' was developed, published and installed by a developer named 'Jack' on a NAV Server Instance named 'NAVDemoService'. A few days later Jack is out of reach and 'Jill' (another developer) wants to know that what objects were modified and created by Jack and packaged in My_Location_Extension.

These kind of scenarios happen in real world. I tried to find a PowerShell cmdlet for unpacking a NAV app package but no success.

So, what to do? Other questions which arise in such a situation are,

• How will Jill be able to know what modifications Jack did in the database? 
• What if Jill doesn't even have the .navx package file? Even if Jill has the .navx package file, it would not help because of the very reason I am writing this post, How to unpack this package file?
• Worst case - Jill has the requirement document but a technical design document isn't there. (This has happened with a lot of us many a times, sure has happened with me. Just in case the project is not very strict with the documentation).

Ideas which come to my mind to handle such a situation:

1. Try to find the modified objects which were exported by Jack, at the time of developing the extension, somewhere in development server. (Not a bad idea, only if Jill can find these objects which could take time and maybe sixth sense :p)
2. No. 1 is the only idea which is coming to my mind, please comment your ideas which may help in such a situation.

So, what to do?

Here goes the answer, It's easier to stop something happening in the first place than to repair the damage after it has happened.

This has been taught to us!

My suggestion to avoid the situation which has happened with Jill: 

Keep a copy of the all the databases on which you have installed extensions (or the databases which you are planning to move to extensions model) in which all the modified objects exist at all times.

Name this database as the Development database which exists in parallel to the database on which extensions are installed.

Tips to maintain this parallel development database,

• Update the documentation trigger and mention that this particular object is used in "this" particular extension.
• Do the same for new objects and new fields, give a note that in which tenant and server instance is "this" extension published and installed.

Therefore, keep 2 databases for working with extensions. 1st in which the extensions are installed and 2nd is the development database in which the modified objects exist. So that multiple developers can work with ease with the same database and the modifications to the database are transparent. Every other developer working on your projects knows what every other developer is up to.

That's all for this post. And like I said earlier in this post, please add your better suggestions and ideas in comments so that it helps everyone in the NAV community.

Keep Learning!

Cheers,

Ishwar