Is your feature request related to a problem? Please describe.
We're using Microsoft-hosted agents for release pipelines (ALOpsExtensionAPI@1).
Currently every run will install the BcContainerHelper and then download the BC-Artifacts.
Describe the solution you'd like
Migrate from importing the .dll files from the artifacts, to the new altool which come with the AL Language extension version 13.0.
I believe this will bring multiple benefits
Improve stability (prevent breaking on breaking changes in artifacts)
Prevent possible refactoring in the future when the artifacts are replaced with NuGet feeds
Improve duration when Default Assemblies not found. Load via BC-Artifacts. is needed. This will take up to almost 4min. Downloading the AL Language extension and grabbing the altool could be faster I believe.
No longer dependent on the BCContainerHelper
Enable the ALOpsExtensionAPI to run with a vmImage: 'ubuntu-latest' Microsoft-hosted agent (there's a Windows and Linux binary available)
To support a gradual transition it would be helpful If we could switch between the current implementation and the new altool. Ideally a ALOpsExtensionAPI@2 step, but a flag/setting on the current ALOpsExtensionAPI@1 also could suffice. Not sure what is most feasible to create, and we should leave the implementation details to you of course :-)
Is your feature request related to a problem? Please describe. We're using Microsoft-hosted agents for release pipelines (ALOpsExtensionAPI@1). Currently every run will install the BcContainerHelper and then download the BC-Artifacts.
Describe the solution you'd like Migrate from importing the .dll files from the artifacts, to the new altool which come with the AL Language extension version 13.0.
I believe this will bring multiple benefits
Default Assemblies not found. Load via BC-Artifacts
. is needed. This will take up to almost 4min. Downloading the AL Language extension and grabbing the altool could be faster I believe.vmImage: 'ubuntu-latest'
Microsoft-hosted agent (there's a Windows and Linux binary available)To support a gradual transition it would be helpful If we could switch between the current implementation and the new altool. Ideally a ALOpsExtensionAPI@2 step, but a flag/setting on the current ALOpsExtensionAPI@1 also could suffice. Not sure what is most feasible to create, and we should leave the implementation details to you of course :-)
Additional context![image](https://github.com/HodorNV/ALOps/assets/44637996/a8467c35-3cf4-454c-a9b4-eb3885994bcd)