[Bug]: correct external appsource dependency not used when skipping docker (useCompilerFolder = true, doNotPublishApps = true)

[SteveKrisjanovsD365]

AL-Go version

6.0

Describe the issue

We have an AL-Go appsource repository that depends on a third party appsource app not published by us. The publisher for that app hasn't provisioned a private nuget feed for their apps yet, so we're using the installApps property for now.

our [main] branch in our repository currently targets BC24. as such, the installApps points to an appsource app URL (not a symbols-only package, and not a runtime package) targeted for runtime 13.0.

the build pipeline fails because AL-Go seems to be fetching the BC25 version (runtime 14) of that third party app, not the BC24 version (runtime 13), nor does the pipeline to use the BC24 version appended to installApps.

when we use docker for compilation and publishing (useCompilerFolder = false, doNotPublishApps = false), the nuget packags is ignored and the installApps version is used.

Expected behavior

when no private nuget feeds nor installApps settings are used, nuget should download the correct nuget symbols package based on the BC version our app is targeting. When there is an installApps URL, use that app and not the nuget package.

this should behave like this both when docker is used and when docker is skipped.

Steps to reproduce

sceenario 1)

create an AL-Go repo (either appsource or PTE), add a new app to it. target BC24. skip docker (useCompilerFolder = true, doNotPublishApps = true)

add a dependency to a third party appsource app. the appsource app should have versions for both BC24 and BC25 available.

the build pipeline will fail since it will try to build your BC24 app with a dependency that targets BC25 and newer

scenario 2)

create an AL-Go repo (either appsource or PTE), add a new app to it. target BC24. skip docker (useCompilerFolder = true, doNotPublishApps = true)

add a dependency to a third party appsource app. the appsource app should have versions for both BC24 and BC25 available.

get a full app or runtime package of the third party app (not a symbols package) and add it to installApps.

the build pipeline will fail since it will try to build your BC24 app with a dependency that targets BC25 and newer, and the installApps version is ignored.

Additional context (logs, screenshots, etc.)

No response

[StefanMaron]

I am experiencing the same issue with a repo thats on version 24.5 since the customers Production environment is not yet on v25.

It seems like the pipeline will always download the very lastest version of an appsource dependency. When running the pipeline against the lastest bc version (25.2) it succeeds without issues.

I am running on AL-Go 6.2

EDIT:

I use artifact: //*// in settings to compile CI/CD against the application version so I can keep that version in sync with the customers production version

[SteveKrisjanovsD365]

@StefanMaron FYI my current workaround to this is to use the installApps property to download a non-nuget version of the appsource app. In our algo repo, our BC24 branch downloads the v24 version. Our BC25 bramch downloads the v25 version.

Since algo nuget functionality is still new and evolving, none of our appsource partners are leveraging nuget yet for private nuggets so it hasn't gained critical mass yet. I would prefer to use private nuget repos to get full apps instead of public symbols-only apps but it's not going to happen yet

[StefanMaron]

@SteveKrisjanovsD365 Is there a way to get that non-nuget version from appsource? Or did you request the runtime version from the ISV and stored that somewhere?

[SteveKrisjanovsD365]

@StefanMaron not that I know of. Our appsource partners host their appsource apps securely on their respective websites (SharePoint, support portal, etc) which we have access to.

[StefanMaron]

Just confirmed, this works.

  "installApps": [
    "https://dynamicssmb2.pkgs.visualstudio.com/571e802d-b44b-45fc-bd41-4cfddec73b44/_packaging/3f253fc9-be40-4eb5-b0e5-1a277ee0ed60/nuget/v3/flat2/binarystreamsoftwareinc.binarystreaminclicensemanagemen.symbols.3c959f73-5fef-46ac-a8cf-0da8f7260611/1.39.0/binarystreamsoftwareinc.binarystreaminclicensemanagemen.symbols.3c959f73-5fef-46ac-a8cf-0da8f7260611.1.39.0.nupkg",
    "https://dynamicssmb2.pkgs.visualstudio.com/571e802d-b44b-45fc-bd41-4cfddec73b44/_packaging/3f253fc9-be40-4eb5-b0e5-1a277ee0ed60/nuget/v3/flat2/binarystreamsoftwareinc.multi-entitymanagementna.symbols.e7e4551c-46e4-40a0-98aa-d33dc1d10bde/1.1.119/binarystreamsoftwareinc.multi-entitymanagementna.symbols.e7e4551c-46e4-40a0-98aa-d33dc1d10bde.1.1.119.nupkg"
  ]

Constructing those URLs is not trivial, but its possible.
But still just a workaround, not really practical as a long time solution.

[SteveKrisjanovsD365]

@StefanMaron agreed its not trival, nor feasible since symbols-only apps in the public msft nuget (this is by design to protect appsource intellectual property) cannot be used for publishing to docker for improved CICD pipeline validation.

if this issue# is plaguing public nugets, I'd wager it would affect private nugets as well

[freddydk]

Yeah - it seems like a bug that with compilerFolder it seems like we do not get the BC version included when searching for NuGet - will have a look at this

[StefanMaron]

@StefanMaron agreed its not trival, nor feasible since symbols-only apps in the public msft nuget (this is by design to protect appsource intellectual property) cannot be used for publishing to docker for improved CICD pipeline validation.

if this issue# is plaguing public nugets, I'd wager it would affect private nugets as well

@SteveKrisjanovsD365 Yes, its symbols only which is why I have the useCompilerFolder and doNotPublishApps set. I have separated my apps now in two different AL-Go projects, MainApps and BridgeApps. The main apps compile and test using docker, the bridge apps are set up to only compile, without docker. This works with just the symbols. Should a partner provide a nuget feed with runtime apps in the future, I can easily move that "bridgeApps" to also be compiled with docker again.