Compile-AppInNavContainer symbol files for Microsoft_Application are missing customization

[ichladil]

I am using container with enabled symbol loading and imported Test Libraries. The app.json does not include Test. Compilation via Compile-AppInNavContainer is failing on the missing test libraries references.

I have checked it a bit further: When manually downloading symbols via VS Code the Microsoft_Application includes the test libraries. When using Compile-AppInNavContainer the downloaded Microsoft_Application is missing the test libraries. Version of the Microsoft_Application also differs in those scenarios.

I assume this is caused by versionText parameter in Invoke-RestMethod which in VS Code is taken from app.json - as it is (13.0.0.0). Whereas in Compile-AppInNavContainer the versionText for Application seems to be overriden by Version provided by Get-NavAppInfo -SymbolsOnly section (13.0.26556.0 in my case of CU2)

[freddydk]

The Test symbols are special I think - doesn't VS Code get these into a specific file?

[ichladil]

Test symbols shall not be handled in the special way if the objects are imported into BC using generatesymbolreferences (and that is the case in my example). My main point is that Application symbols exported from BC container when using Compile-AppInNavContainer exports out-of-the-box DVD symbol references only ignoring the fact that I have modified via C/SIDE or via objects import some further objects into BC application.

If the line $version = $app.version is executed only if publisher <> 'Microsoft' or name <> Application the result would be perhaps correct even in this scenario.

[freddydk]

I am having a hard time reproing this - I might be doing something wrong??? If you can share a PowerShell script showing what goes wrong - that would be helpful.

[NAVFreak]

This could be divided into two issues:

1. Compile-AppInNavContainer doesn't compile with the same symbols as VS Code does (my pull request)
2. The imported CSIDE objects are not included in the symbol files when choosing the same app version as the same one installed.

For number 2 i have filed a support request to Microsoft.

[freddydk]

I just talked to the guys from the modern dev team. The interesting thing is to find out how you got the two different versions of the symbols in there in the first place. If you run Get-NavContainerAppInfo with -symbolsOnly what do you get? I get:

ServerInstance : MicrosoftDynamicsNavServer$NAV
PSComputerName : a863168e31d2a77ade77af5a4ca3cd8bf9298de61eed88202a736cfef4a8da64
RunspaceId     : 37c8e6ae-9522-4f1b-967a-0171dd4ea0bb
AppId          : 0b15f250-c24a-416c-85c0-ec2f978d1fbb
Name           : Application
Publisher      : Microsoft
Version        : 13.3.27233.0
ExtensionType  : ModernDev
Scope          : Global

ServerInstance : MicrosoftDynamicsNavServer$NAV
PSComputerName : a863168e31d2a77ade77af5a4ca3cd8bf9298de61eed88202a736cfef4a8da64
RunspaceId     : 37c8e6ae-9522-4f1b-967a-0171dd4ea0bb
AppId          : c4b9245c-67fa-4256-94b8-6efd189d5e5e
Name           : Test
Publisher      : Microsoft
Version        : 13.3.27233.0
ExtensionType  : ModernDev
Scope          : Global

ServerInstance : MicrosoftDynamicsNavServer$NAV
PSComputerName : a863168e31d2a77ade77af5a4ca3cd8bf9298de61eed88202a736cfef4a8da64
RunspaceId     : 37c8e6ae-9522-4f1b-967a-0171dd4ea0bb
AppId          : 8874ed3a-0643-4247-9ced-7a7002f7135d
Name           : System
Publisher      : Microsoft
Version        : 13.0.12929.0
ExtensionType  : ModernDev
Scope          : Global

Which is one symbols app of each.

[NAVFreak]

Same as you:

ServerInstance : MicrosoftDynamicsNavServer$NAV
PSComputerName : eaf3ac8ec6b731a72236ca9a5ddd0aa79423d302972129200d0d7268b83d9ff6
RunspaceId     : 736de200-8c2a-4d14-a961-e12e78aa1613
AppId          : c2416346-b0ef-43a0-a97f-0cbc72bbcf28
Name           : Application
Publisher      : Microsoft
Version        : 13.3.27233.0
ExtensionType  : ModernDev
Scope          : Global

ServerInstance : MicrosoftDynamicsNavServer$NAV
PSComputerName : eaf3ac8ec6b731a72236ca9a5ddd0aa79423d302972129200d0d7268b83d9ff6
RunspaceId     : 736de200-8c2a-4d14-a961-e12e78aa1613
AppId          : c4b9245c-67fa-4256-94b8-6efd189d5e5e
Name           : Test
Publisher      : Microsoft
Version        : 13.3.27233.0
ExtensionType  : ModernDev
Scope          : Global

ServerInstance : MicrosoftDynamicsNavServer$NAV
PSComputerName : eaf3ac8ec6b731a72236ca9a5ddd0aa79423d302972129200d0d7268b83d9ff6
RunspaceId     : 736de200-8c2a-4d14-a961-e12e78aa1613
AppId          : 8874ed3a-0643-4247-9ced-7a7002f7135d
Name           : System
Publisher      : Microsoft
Version        : 13.0.12929.0
ExtensionType  : ModernDev
Scope          : Global

But this doesn't matter, even though it only lists ONE application it obviously returns different symbols files depending on which version you add as a parameter. If you do a manual build (CTRL +F5) you can see in the output window it adds 13.0.0.0 in the call

[2019-02-19 10:28:39.13] Using reference symbols cache path: c:\GIT\norrvidinge-base-app\App\.alpackages
[2019-02-19 10:28:39.21] Sending request to http://<ContainerName>:7049/NAV/dev/packages?publisher=Microsoft&appName=Application&versionText=13.0.0.0
[2019-02-19 10:28:39.22] Sending request to http://<ContainerName>:7049/NAV/dev/packages?publisher=Microsoft&appName=System&versionText=13.0.0.0
[2019-02-19 10:28:50.20] All reference symbols have been downloaded.

This is the problem with Compile-AppInNavContainer, it uses the version nr it gets from

Get-NAVAppInfo -ServerInstance NAV -SymbolsOnly
http://<ContainerName>:7049/NAV/dev/packages?publisher=Microsoft&appName=Application&versionText=13.3.27233.0
$url = "$devServerUrl/dev/packages?publisher=${publisher}&appName=${name}&versionText=${version}&tenant=$tenant"

So what we have is that it returns different symbol file depending on which paramater you use in the download symbols call. Is this right, I don't know thats for you (MS) to decide ;)

Until it is decided I did the workaround for Compile-AppInNavContainer that used the version in App.json instead of the ones the server says it has.

[ichladil]

I can just confirm @NAVFreak observations, with the following additions: I'd add that even though my SymbolsOnly references are the same as yours (Application has version = 13.3.27233.0), the file retrieved by VS Code is Microsoft_Application_13.0.27183.0.app

In order to reproduce the above results I have just instatiated the following container: New-NavContainer -containerName bclocal -imageName mcr.microsoft.com/businesscentral/onprem:cz -enableSymbolLoading -includeTestToolkit -includeTestLibrariesOnly -accept_eula -auth NavUserPassword

I also tested it without enabledSymbolLoading and the VS Code downloaded original Microsoft_Application_13.3.27233.0.app as expected.

[freddydk]

I have been investigating this and now I know what goes wrong. The Pull Request which fixes this, fixes the symptom, but it is the wrong fix. The real problem is, that the application version is wrong in local Business Central On Prem builds. the 13.0.27183.0 is actually the platform version number used as application version number. W1 uses the correct application version number 13.3.27233.0. The bre-built symbols.app which has been published during build also uses the correct version number 13.3.27233.0 (Get-NavAppInfo). But when enabling symbolLoading and generating new symbols (or changes to symbols), it uses the applicationVersion from the database (13.0.27183.0). This means that if you download apps using 13.0.0.0 you get the lower number - which fortunately is the correct one.

The right fix is to ensure that the applicationVersion number in the database is correct. That should be done in the build process. If you want to do it after creating the container you need to do like this:

    Invoke-ScriptInNavContainer -containerName $containerName {
        $databaseName = Get-NAVServerConfiguration -ServerInstance NAV -KeyName DatabaseName
        $applicationVersion = (Get-NAVAppInfo -ServerInstance NAV -Name Application -SymbolsOnly).Version.ToString()
        Invoke-SqlCmd -Database $databaseName -Query "update [dbo].[$("$")ndo$("$")dbproperty] SET [applicationversion] = '$applicationVersion'"
        Invoke-SqlCmd -Database $databaseName -Query "update [dbo].[$("$")ndo$("$")tenantproperty] SET [applicationversion] = '$applicationVersion'"
        Sync-NavTenant -ServerInstance NAV -tenant default -mode ForceSync -Force
    }
    Generate-SymbolsInNavContainer -containerName $containerName

but this takes a lot of time during container creation. Another fix, which might be fine (for now) is to simply unpublish the wrongly numbered app symbols after creating the container:

UnPublish-NavContainerApp -containerName $containerName -appName Application

That is fast and will cause Compile-AppInNavContainer to use the app.json version number. I suggest you do this for now - and I will file a bug on the build team

[ichladil]

Thanks @freddydk for the suggested workaround. It works well for me ...

[NAVFreak]

The workaround works, but we need to do something with Compile-AppInNavContainer. I fixed this "bug" that it doesn't try the application version from app.json on my build agent but since it automatically fetches new newest version of navcontainerhelper I'll have to update it everytime at every release or turn off the automatic update. None of the options are really good. What do we need in order to update Compile-AppInNavContainer so it uses the application version in app.json instead of the application version that is currently installed on the server?

I still think that it doesn't use the application version in app.json is a bug. Because that is what compiler in VS Code does.

[freddydk]

Have been busy - I will fix this in the right way in the next version of NavContainerhelper

[freddydk]

Shipped in 0.5.0.5