Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AL1032 error building package for OnPrem customized base app #769

Closed
TheDenSter opened this issue Nov 24, 2019 · 15 comments
Closed

AL1032 error building package for OnPrem customized base app #769

TheDenSter opened this issue Nov 24, 2019 · 15 comments

Comments

@TheDenSter
Copy link

@TheDenSter TheDenSter commented Nov 24, 2019

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

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

This comment has been minimized.

Copy link

@PooyaKharamesh PooyaKharamesh commented Nov 26, 2019

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 comment has been minimized.

Copy link

@NKarolak NKarolak commented Nov 26, 2019

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

This comment has been minimized.

Copy link
Author

@TheDenSter TheDenSter commented Nov 26, 2019

I did not rename anything, the translation files come right out of the container.
image
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

This comment has been minimized.

Copy link

@NKarolak NKarolak commented Nov 27, 2019

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

This comment has been minimized.

Copy link
Author

@TheDenSter TheDenSter commented Nov 27, 2019

I must say I was skeptical about your suggestion Natalie, but I figured it was worth a try.
image
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.
image
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

This comment has been minimized.

Copy link

@NKarolak NKarolak commented Nov 27, 2019

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

This comment has been minimized.

Copy link
Author

@TheDenSter TheDenSter commented Nov 27, 2019

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

This comment has been minimized.

Copy link

@NKarolak NKarolak commented Nov 27, 2019

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

This comment has been minimized.

Copy link
Author

@TheDenSter TheDenSter commented Nov 27, 2019

Yes I think it must have changed recently,

@thpeder

This comment has been minimized.

Copy link
Member

@thpeder thpeder commented Nov 28, 2019

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

This comment has been minimized.

Copy link
Author

@TheDenSter TheDenSter commented Nov 28, 2019

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

This comment has been minimized.

Copy link

@PooyaKharamesh PooyaKharamesh commented Nov 29, 2019

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

This comment has been minimized.

Copy link
Contributor

@freddydk freddydk commented Nov 30, 2019

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).

@freddydk freddydk reopened this Nov 30, 2019
@freddydk freddydk transferred this issue from microsoft/AL Nov 30, 2019
freddydk pushed a commit that referenced this issue Nov 30, 2019
@freddydk freddydk mentioned this issue Nov 30, 2019
Merged
@TheDenSter

This comment has been minimized.

Copy link
Author

@TheDenSter TheDenSter commented Nov 30, 2019

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

This comment has been minimized.

Copy link
Contributor

@freddydk freddydk commented Dec 10, 2019

Fixed in 0.6.4.21

@freddydk freddydk closed this Dec 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.