Extension 1.0 to Extension 2.0: ID, Name, Publisher conflict

[hvogelpohl]

Hello,

I need someone's advice, please.
I would like to update an extension that has been in the appsource for 2 months now. This extension is also existing in the sandbox I'm working with during development.

Now my stupid questions are this:
Which Extension ID do I use? A new extension or the ID of the extension to be updated? How do I update in this scenario at all?

The problem I have at the moment is that the extension can't be updated when publishing (I converted the extension to 2.0 and hit F5).
The request for path /v1.0/sandbox/dev/apps failed with code 422. Reason: The following SQL error was unexpected:
There is already an object named 'CRONUS US$Some Table Name' in the database.

I'm using same id, same name, same publisher of my extension 1.0, existing in the sandbox.

I think I have an understanding problem :-(

Let me apologize ahead of time for the verboseness. There is a lot of stuff implicit to your question

Answer to the not-so-stupid question around Extension ID (AppID):

You should think of converting from Ext 1.0 to 2.0 in the same way as you would when writing a new version of your extension: New version number, source changes, new upgrade code.
The AppID is an identifier for the extension across ALL versions and should never change for a given extension. Doing so is effectively saying "this is a different extension altogether". Since we're treating this conversion as 'just' a new version, then the ID should remain the same.

Answer to the error you're hitting "There is already an object....":

The Extensions 2.0 processes around creating tables in the database do not recognize or automatically 'clean up' tables from Extensions 1.0. So what's happening here is that the 2.0 process is trying to create the extension's tables in SQL and it's conflicting with the existing 1.0 tables.
This is the expected behavior as a result of the way we synchronize the SQL database for extensions 2.0. The solution (which I outline again later) is to uninstall your 1.0 extension. This removes the 1.0 tables from SQL and allows them to be recreated by the 2.0 extension.

So how do I write upgrades for 2.0:

In the October release we added the ability to write upgrade code to migrate data from an Ext 1.0 into 2.0. Online documentation is still forthcoming, however, the gist of it is to include upgrade codeunits (i.e. Subtype=Upgrade) in your extension source and write your upgrade logic there.

Differences from Ext 1.0:
The magic upgrade functions you wrote in 1.0 (OnNavAppUpgrade*) are no longer used. Instead, we added new triggers implicit to the syntax of upgrade codeunits:

• OnCheckPreconditions* - Used to check that we 'can' upgrade
• OnUpgrade* - Used to do actual upgrade work
• OnValidateUpgrade* - Used to check that upgrade was successful
• OnAfterUpgradeCommit* - Used to perform any small 'post-upgrade' tasks
  *Each of these has a PerDatabase & PerCompany flavor

So for Ext 2.0 you MUST utilize these new triggers if you want any of your upgrade logic to run

As if that wasn't enough, we've also added some new API's accessible from within AL that you can use to determine important upgrade related information.
This info is encapsulated in a new AL call 'ModuleInfo'.
Most important on this type for 'upgrade' is the 'DataVersion' property, which tells you what version of data you are dealing with.
You can access this info using the NAVAPP object, via the GetCurrentModuleInfo() method

Example:

//_PerCompany_ triggers omitted for brevity
codeunit 70000001 MyUpgrade
{
    Subtype=Upgrade;
    
    // Runs 1st
    trigger OnCheckPreconditionsPerDatabase();
    var 
        myInfo : ModuleInfo;
    begin
        // Code to check if database state is OK before upgrading
        // For example, something to check what old data you are coming from
        if NavApp.GetCurrentModuleInfo(myInfo) then
            if myInfo.DataVersion = Version.Create(1, 0, 0, 1) then
                ERROR('INCOMPATIBLE UPGRADE, OH NO!'); 
    end;

    // Runs 2nd after check preconditions
    trigger OnUpgradePerDatabase();
    begin
        // Code to perform the upgrade
    end;

    // Runs 3rd after upgrade
    trigger OnValidateUpgradePerDatabase();
    begin
        // Code to check that upgrade was successful
    end;

    // Runs 4th after previous 3 steps are COMMITTED
    // Additionally, any errors thrown here do not 'fail' the upgrade
    trigger OnAfterUpgradeCommitPerDatabase();
    begin
        // Code for any post upgrade logic
    end;
}

Ok OK! Got all that, but "how do I use this with 1.0!":

Upgrading data from a 1.0 extension to 2.0 is done in a similar manner to the old upgrade model.

In your 2.0 upgrade code, you utilize the old NAVAPP.* functions to access 1.0 archived data. Note that this means if you want to use NAVAPP.RESTOREARCHIVEDATA(), that you need to make sure that your table ids stay the same across 1.0 to 2.0, otherwise you'll have to use NAVAPP.GETARCHIVERECORDREF() and manually port every field from the archive into your new 2.0 tables.

As you've already seen, the 2.0 extension tables are going to conflict with those from 1.0, so as the previous section might suggest, you must first uninstall the 1.0 extension before upgrading to 2.0.
This puts the data into archives and removes the 1.0 tables from SQL so that the 2.0 version can be synchronized.

So, once you've uninstalled the 1.0 extension, and published/synced the 2.0 version, you can kick off an upgrade and, baring logic errors or... bugs... you should be 'good-to-go'

Sweet! So how do I run upgrades?

Currently, there is no support for running 'upgrades' from within VSCode, so the F5 scenario you've noted isn't going to work. That being said, you can still invoke/test the upgrade 'manually' via the powershell cmdlets.

Ext 2.0 keeps the same management cmdlets as 1.0 but adds 2 new ones that you need to utilize for them to work.

• Sync-NavApp - Synchronzies 2.0 tables to SQL schema
• Start-NavAppDataUpgrade - Upgrades an extension to a specific version

So let's assume your 1.0 extension is called 'ProfitMaker' and is at version '8.8.8.0'. It's published, installed, and populated with data. Your 2.0 version is called the same thing, (with the same AppID), but is at version '10.0.0.0' because we like nice 'even' numbers. Let's also assume that your server instance is called 'NAV' and that you have only 1 tenant for simplicity.

In order to 'upgrade' you would need to execute the following:

1. Uninstall the 1.0 extension
   Uninstall-NavApp -ServerInstance NAV -Name ProfitMaker -Version 8.8.8.0

   • Removes tables from SQL and archives extension data

2. Publish the 2.0 extension (assuming it isn't signed yet)
   Publish-NavApp -ServerInstance NAV -Path .\ProfitMaker_10.0.0.0.app -SkipVerification

   • Validates extension syntax against server and stages it for syncing

3. Sync the 2.0 extension
   Sync-NavApp -ServerInstance NAV -Name ProfitMaker -Version 10.0.0.0

   • Adds tables from extension to SQL

4. UPGRADE!!!
   Start-NavAppDataUpgrade -ServerInstance NAV -Name ProfitMaker -Version 10.0.0.0

   • Runs upgrade logic from specified extension to port data from old installations

5. (optional) Unpublish the 1.0 extension
   Unpublish-NavApp -ServerInstance NAV -Name ProfitMaker -Version 8.8.8.0

   • Removes unused extension package from server

Again, sorry for the mass of knowledge, I hope that starts to answer your question.

[hvogelpohl]

Thank you very much. I‘ll try this asap. 👍🏻