AL1032 error building package for OnPrem customized base app

[TheDenSter]

Describe the bug
Building the package for modified base app results in an error message:

To Reproduce
It's actually difficult to reproduce. I get the error just once, only for a brand new container. It only seems to show the error message when I delete any existing packages. The next time I build the package it does not specify the error in the output window, but it does fail.

• New BC OnPrem container
• Create AL Project file: Create-AlProjectFolderFromNavContainer
• Run Package from the command palette

Expected behavior
I'd expect to be able to build the package with the AL project folder that is exported from the container. When I remove all translations files, it does compile.

5. Versions:

• AL Language: 4.0.199169
• Business Central: NA Business Central 15.1 (Platform 15.0.37898.0 + Application 15.1.38071.0)
• Docker image: mcr.microsoft.com/businesscentral/onprem:na-ltsc2019

[PooyaKharamesh]

would you add a sample project or some code snippet that clearly repro the issue. It will help us to prioritise and address the issue faster.

/Pooya

[NKarolak]

This error usually occurs whenever you rename your app, with translation files already existing for the old app name, since you may have only one translation file per language.
That's why this worked for you:

When I remove all translations files, it does compile.

So when it happens again, it' worth checking the translation file names.

[TheDenSter]

I did not rename anything, the translation files come right out of the container.

Nothing changed in app.json either, all standard values from the container.

would you add a sample project or some code snippet that clearly repro the issue. It will help us to prioritise and address the issue faster.

New container, export the AL project folder, uninstall/unpublish the Base App and its dependencies, then building the package causes the error. The actual error message about the translation files only happens the first time on a fresh container. I've had it where it successfully builds the app file but it will not publish to the container. Then when I remove the translation files it works again.
I wrote a blogpost about what I did: http://thedenster.com/modified-base-app-on-docker

[NKarolak]

I did not say that it was you who renamed anything ;-)
However, I've customized a base app as well, and what looks different for me is the name of the translation files. Mine are not Base%20Application.*, but Base Application.*
My app.json contains
"name": "Base Application",
If this name is the same on your side, I wonder why your translation file names contain / are created with the %20?

[TheDenSter]

I must say I was skeptical about your suggestion Natalie, but I figured it was worth a try.

It worked!
The error message says that there are two translation files with the same target language. This is true because the '*.g.xlf' file has the en-US target and so does the 'real' translation file. Besides the fact that the g.xlf file should really be ignored here, this isn't even relevant because the actual problem seems to be with the name of the translation files.

So then I changed the name in app.json, and then it creates the new package but it fails to publish to my container. I then renamed the translation files to match the new name in app.json and it worked again.

The translation files NAME seems to have a correlation to the name property in app.json, which is not documented anywhere I don't think.

[NKarolak]

I should have been clearer in my initial reply.
When I renamed the app name earlier myself, I ran into your error but luckily saw very soon that VS Code tried to generate the translation files with the new app name. Thus removing the old translation files was the solution. That's why I said

whenever you rename your app, with translation files already existing for the old app name

Anyway, I'm glad it helped you.

[TheDenSter]

The important part is eventually I understood what you meant. Thank you for your help, I would not have tried that. I wrote a follow up here.

[NKarolak]

I've answered to your blog article, but I fear my browser did not pass it for whatever reason. To be sure, I enter it here again:

this was never the case in any of the AppSource apps I’ve worked on

And I have encountered it exactly there, while programming an AppSource app for BC15 ;-)
So if you renamed your apps earlier without any issues, maybe the translation file naming requirement changed between BC14 and BC15?

[TheDenSter]

Yes I think it must have changed recently,

[thpeder]

The bane of the issue is that there are two translation files with the same target-language and the compiler can't recognize that one of them is the generated file.

When the feature flag TranslationFiles is enabled that will make the compiler generate a template translation file .g.xlf and read all the translation files in the translations folder.
The compiler will give an error when it sees multiple translation files with the same target-language with one exception, that it ignores the generated file, and the means it uses to find the generated file is by the filename.

As you have discovered the generated translation file has the wrong filename.

[TheDenSter]

I don't know if that's accurate because once I rename the files to match the name in app.json, I no longer get the error message and the build succeeds and the app publishes. Seems to me like it is displaying the wrong message.

By the way, it only shows the message when I build the package. When I hit F5 or Ctrl+F5 it does not write the message to the output/debug window, it just says 'could not publish' with the button to open launch.json

[PooyaKharamesh]

I am closing this issue because it appears that it has been resolved. Please open a new issue if you believe this has not been resolved and reference the current issue.

[freddydk]

The reason for this problem is, that Extract-AppFileToFolder didn't unescape the filename.
I will fix this in the containerhelper.

Note that you can use -usebaseline, which causes the create-alproject function to grab the baseline of the baseapp and not download and extract the app (and this the problem wouldn't be there).

[TheDenSter]

I had seen the -usebaseline switch but did not see that it also creates the AL folder. I'll look for it because that's probably the best option anyway.

Still leaves the faulty error message :) but that's not yours to fix. Thanks for the follow up!

[freddydk]

Fixed in 0.6.4.21