Publishing complex app dependencies to AppSource

[jonaswre]

This might be related or its atleast is happening in the same repo as #328 was.

To recap, we have the following structure.

RepoA
- AppA 
- AppB
- AppC
- AppD

Each app is its own project because AppA and AppB are not dependent, it might make sense to release them independently.
But from a marketing perspective that currently doesn't make sense.
The dependencies are as following:

AppA <-
        AppC  <- AppD
AppB <-

pardon my ascii...

We've currently only released AppD to AppSource. The rest are libaries.

Firstly if I run the "Publish to AppSource" workflow with the default settings I get the error AppSourceProductId needs to be specified in AppA... AppB... AppC.... It would be good to be able exclude Projects from release. So that I don't need to think about all these little details when releasing any of the 50+ apps. Because thinks like this are bound to be forgotten.

Now comes the Issue:

If I only run the workflow for the project I want to release I don't get any errors but AppA AppB and AppC won't be include as libaries. The worklfow then only updates the main app without any warnings.
This might actually break stuff if the main app is updated but the libraries won't.

To be honest I get why this is a difficult problem to solve. Because Al-Go has no clue which of the dependencies exsits in AppSource and which need to be includes as libraries.

This currently means we need to publish manually or reverting back to only use one Project per repo - which I really don't want to do because, I will have to revert these changes later again.

[jonaswre]

@freddydk did you have time to have a look at this issue?

[freddydk]

Not yet - but this week hopefully

[jonaswre]

As a temporary fix we've now published all the apps to AppSource. But this isn't a viable longterm solution. Maybe I'm missing something, but how does AL-GO determine if dependencies need to be included as libraries or if its already present in AppSource?

[jonaswre]

@freddydk any updates?

[freddydk]

Time flies, working on issues this week - will prioritize this.

[freddydk]

In your example above, AppA, AppB, AppC are only uploaded to AppSource as libraries to AppD?
i.e. - they don't have their own productId.

[jonaswre]

No A,B,C are Dependencies to D. But yes you are right they don't have productIds. But the Issues is the same if you have dependencies you get from github packages. When you need to download your dependencies you wont have any information about the product id.

[freddydk]

Do you have generateDependencyArtifact set to true?
That won't solve the entire problem though.

I think the solution to this is as follows:

1. Set generateDependencyArtifact = true and include dependencies as libraries when submitting (not sure whether that happens today).
2. Have a project setting explaining which dependencies to include in your submission (* would be default and grab all dependencies used for building). There could also be a exclusion list (if you want to include all but one 3rd party dependency)

Agree?

[jonaswre]

Yes I'm already using generateDependencyArtifact.

I guess thats to most generic approch to handling it.
But I don't like if I have to duplicate settings. It would be cool to include a property in the nuspec file and be able to get if from the .AL-Go/settings.json if possible.

[freddydk]

But with a property in nuspec - would you be able to determine which project really should include this and which project shouldn't???

[jonaswre]

If I know which App has a product ID I know that I don't need to include it and it's dependencies right?

[freddydk]

I assume that this was fixed when adding the IncludeDependencies property in the DeliverToAppSource setting.
See https://aka.ms/algosettings#delivertoappsource

[jonaswre]

It was definitly resolved. He have releases recently a few apps that had non AppSource dependencies. But it works now