⚠️ Please don't use the experimental tool PASOPA in production ⚠️

[marcelbf]

This repo contains the legacy PASopa tool to unpack a .msapp and is no longer supported. The pac solution command with the --processCanvasApps parameter also uses this tool and will be deprecated. To source control your canvas app, please use the Power Platform git integration.

More information about the YAML serialization format is available in the documentation.

[h-karthik12]

HI @marcelbf
Pac canvas unpack is also throwing the error when tried to unpack the .msapp file . We are using this command to unpack and edit the instrument key for the higher env. so Pac Canvas unpack pac cli command is absolute now?

[marcelbf]

I assume you're talking about the connection string to connect canvas to a AppInsights instance.
For this scenario unfortunately there's no supported way to update the connection string in the pipeline at this point.

For consistent telemetry and ALM-friendly setup, we recommend binding your Canvas app to a single Application Insights instance across all environments (Dev, Test, Prod). This allows you to:

• Centralize telemetry: All environments log to the same App Insights instance.
• Filter by environment: Use custom dimensions (e.g., environment name) to segment data in dashboards.
• Simplify ALM: Avoid hardcoding instrumentation keys or using PAC CLI to update them post-deployment.

This approach is secure and supported. The App Insights connection string is not a secret, and centralizing telemetry does not introduce additional security risks.

Example: If a performance issue is detected in production, you can compare it with telemetry from Dev or Test in the same dashboard to validate fixes.

[fowl2]

This repo contains the legacy PASopa tool to unpack a .msapp and is no longer supported. The pac solution command with the --processCanvasApps parameter also uses this tool and will be deprecated. To source control your canvas app, please use the Power Platform git integration.

Hi @marcelbf note that many people aren't aware they're using "PASopa". We just use the "process canvas apps" tick box in the Power Platform build tools actions in Azure DevOps.

[fowl2]

I would suggest adding "--extractCanvasApps" parameter (and corresponding parameter in the PPBT) to give people 1:1 migration path.

I don't see any point in investigating the built in Git integration as it requires premium licensing. A significant reason we're using (and were sold on!) canvas apps is because they don't require premium licensing. It's not a great look to be deprecating existing functionality to force a more expensive license.

Back link to PPBT issue: microsoft/powerplatform-build-tools#1246

[marcelbf]

Thank you @fowl2 for your suggestion.

I just want to ratify; this is not a deprecation of an existing functionality. This is the removal of an unsupported tool. It is not reliable and sustainable to keep this tool in your pipeline.

That said, I did merge a fix for this #762, but this tool keeps unsupported. Building a local version of this repo and use it to unpack should work.

The Fix IS NOT included in PAC CLI.

[fowl2]

I'm proposing adding the replacement functionality - extracting the msapp - to the PAC CLI. If the PAC CLI was open source I'd even consider creating a PR. Alas.

Edit: and even the PAC CLI is an implementation detail - again, I'm actually looking for a solution using the Power Platform Build Tools. It's not even possible to specify a specific version of the PAC CLI, let alone swap out some transitive dependency.

[petrochuk]

I'm proposing adding the replacement functionality - extracting the msapp - to the PAC CLI. If the PAC CLI was open source I'd even consider creating a PR. Alas.

Edit: and even the PAC CLI is an implementation detail - again, I'm actually looking for a solution using the Power Platform Build Tools. It's not even possible to specify a specific version of the PAC CLI, let alone swap out some transitive dependency.

What kind of functionality would be useful in PAC CLI? There is an existing pac canvas download docs: with --extract-to-directory argument which does "unzip".

[fowl2]

The parameter would be on the unpack operation, and it would extract each canvas app included in the solution. Sure this is "just" glue code, but it's glue code that's otherwise going to have to be rewritten (badly) by everyone trying to transition from something that currently works.

Again, I'm just trying to maintain the existing functionality in my DevOps pipelines. It's already a pain having to update 20+ pipelines to add a "continue on error".

[h-karthik12]

Yes, https://learn.microsoft.com/en-us/power-platform/developer/cli/reference/canvas
Still its in public preview. But this feature is good to have and request Microsoft and D365 team to not to deprecate those

[marcelbf]

Yes, https://learn.microsoft.com/en-us/power-platform/developer/cli/reference/canvas Still its in public preview. But this feature is good to have and request Microsoft and D365 team to not to deprecate those

this command is PASOPA and it won't move to GA.

[rssb-jabols]

I have situations where the git integration doesn't work - I'm getting errors along the lines of "solution is too large" (it's been a few weeks since I last tried, if it's useful I can try to reproduce the exact issue).

Is the plan for the git integration to replace all deployment pipelines? I.e., can a "managed" solution also be linked to a specific branch? I sometimes have to cherry-pick canvas code for releases - the ability to manipulate canvas source code pre-deployment is very useful, so I hope, regardless of the exact mechanism for getting the canvas source, that we will still be able to pack canvas apps from source in the future, or, if the whole "packing" concept is becoming redundant, merge code directly into a branch that is linked to a higher environment / managed solution.

Lastly, you mention that we can just extract the .msapp file to access the source - is this intended as a workable solution long-term? We have use cases where access to canvas source is very useful, such as reviewing PRs and using AI agents to produce documentation based on the source code.

[marcelbf]

Is the plan for the git integration to replace all deployment pipelines?

Not necessarily.
Git Integration is about enabling everybody to do ALM best practices (including makers) - Pro Devs still can use PAC CLI / PP Build Tools / GitHub Actions to address their needs.

I'm getting errors along the lines of "solution is too large" (it's been a few weeks since I last tried, if it's useful I can try to reproduce the exact issue).

acknowledged - this is a bug. The fix for GIT Integration is rolling out, should be available in a couple of weeks.

I hope, regardless of the exact mechanism for getting the canvas source, that we will still be able to pack canvas apps from source in the future

Acknowledge.
You can unpack the new format. You can't pack today (out of GIT Integration) - we are considering.

Lastly, you mention that we can just extract the .msapp file to access the source - is this intended as a workable solution long-term?

Yes, this is a workable solution long-term. The YAML serialization happens natively, so every time you save your canvas, YAML source will be there.

[rssb-jabols]

Hi @marcelbf, thank you very much for your response, it clarifies things a bit.

I really hope that packing canvas apps from source will be a supported action in the long-term, there are many benefits:

• spinning up a clean dev environment from only source code - it is nice to not have to maintain lower environments for months / years while there is no development happening, and only spin up dev-test-uat when necessary, but packing from source is essential here
• cherry-picking features for releases
• quick release of PowerFX-related hotfixes to higher environments
• environment or build -specific changes to app logic or values (where environment variables or the settings file aren't quite cutting it)
  • e.g., application insights key (though I understand there is something in the works to turn this into an env variable)
• certain types of bulk-update, for example, find-and-replace using regex and capture groups (the built-in replacer in the canvas studio doesn't handle capture groups)

It feels like the ability to pack from the source generated by git-integration makes the most sense, but some backwards compatibility is likely required here, to cover the 1st use case from above - there will be solutions out there that only have a prod deployment and old-style source code in the repo, so some means of migrating those to the new world should be provided.

Thank you once again for engaging, and let me know if there are better channels for voicing the above.

[nova-ac]

@marcelbf - Is the full ALM that was offered for 'free' via the COE ALM Templates and Azure DevOps Pipelines now strictly a premium feature? Based on one of your replies, there currently is no alternative to re-packing solutions which include canvas apps from source code outside of the git integration.

[marcelbf]

the propose of the flag is to generate fx.yaml files.

If you do change those files, it does impact the ability to build from source code. The current alternative is GIT Integration.
If you don't change fx.yaml files, it does NOT impact.

[nova-ac]

@marcelbf Outside of the COE ALM templates used in our DevOps pipelines, I've not directly interacted with the PAC CLI's --processCanvasApps true parameter. Any changes to those files would have been through the designer via Power Apps Studio with exports handled by the pipelines. I do not interact with the source files directly and I think that's also the case for others in my org.

Ultimately, I'm trying to determine my next steps to enable our makers to continue updating their apps. From what I gather, my only viable path forward is to obtain premium licenses to support healthy ALM of our canvas apps. Would you agree?

[marcelbf]

Hey @nova-ac - I do not agree - because you mention that any changes to those files would have been through the designer via Power Apps Studio. You don't need Managed Environment to keep doing that.

I'm not aware of all the code in the ALM accelerator, and I don't know how deep is the PASopa dependency, but it looks like all you need to do is not to use the --processCanvasApps parameter.

I'm working with the internal teams to update the guidance on the ALM accelerator BTW. I really appreciate the heads up here with direct link to the ALM accelerator repo. 👍

In the meantime, I have deployed a fix to PASopa, so we can unblock you right now if there's a real need and/or any business impact #762 (you will have to build the tool locally until next PAC CLI release though). I just want to ratify; it is a lot easier just to remove the parameter.

[nova-ac]

@marcelbf I agree with you that we do not need any additional licensing to make changes to the canvas apps, you're right about that.

I'm more focused on automating the extraction, building and deployment (CI/CD) of the maker's changes. This is the part that is broken and I'm looking for guidance on as it seems that not even the pac CLI/PPBT can actually handle the building of canvas apps. It is a bit confusing to me that these are the developer tools offered to interact with power platform, but a critical capability (building canvas apps) seems to have been removed. Is there some alternative I'm missing here? How do people build canvas apps these days from code if not using the pac CLI/PPBT?

Regarding the accelerator, not a problem. I'm glad it has got your attention as the latest issues have all been met with folks informing users that the built-in product (a premium license requiring feature) is the path forward. I took a look at the deployment code, and it also makes use of the pac canvas pack command when attempting to repack the canvas app with the latest changes.

If I were to build the pac CLI locally, how do I make use of it in an azure devops pipeline? We have dozens of solutions that are in use today and being changed and updated across all hours of the day. How far out is the next PAC CLI release?

Thanks again for all your help! Much appreciated.

[nova-ac]

@marcelbf Just wanted to update you. I added the ProcessCanvasApps variable to my pipeline and set it to false. This let me successfully update the changes and solutions at the sacrifice of the historical source code (since we use ephemeral build agents, those directories were removed in the commit). The deployment side seems to test to see if those directories exist and if not just skips them.

So right now, we have only lost the historical diff and build from source which I think can be solved using @Dean-Hornibrook's advice (zip/unzip).

[hi-yamap]

I have been using the pac solution unpack --processCanvasApps command to manage version history of Apps, Power Automate Flows, and environment variables included in a solution collectively with Git.

Since the --processCanvasApps option was deprecated, .msapp files are no longer unpacked, making it impossible to track changes in the Apps — which is causing me serious issues.

As an alternative, I tried unzipping the .msapp files directly as suggested, but the extracted folder structure is completely different from what was produced when using the --processCanvasApps option.

It seems that the process triggered by --processCanvasApps performed additional steps beyond a simple unzip.
Could you please clarify what those additional steps were, or let me know if there’s a replacement command or equivalent process available?

Thank you for your support.

[marcelbf]

@hi-yamap to track changes in an unzipped msapp you only look at /src folder.
https://learn.microsoft.com/en-us/power-apps/maker/canvas-apps/power-apps-yaml#file-structure-for-a-msapp-file

yes, PASopa will do additional transformation, like separating the data sources in individual files.

The native YAML is the serialization of the app element, screens and components.

[hi-yamap]

@marcelbf Thanks, that explanation really helped.
By unzipping the .msapp files, I can indeed continue to manage the source in Git.
However, for solutions that contain many apps, manually unzipping each one is quite cumbersome.

It’d be great if an option similar to --processCanvasApps could be added back to handle this automatically,
so that all apps within a solution could be unpacked in one step, just like before.

[Dean-Hornibrook]

Just adding here from reading this thread and others

the PASopa serialization used on previous versions of canvas apps is no longer in use on the latest authoring version of canvas apps.

these .msapp files are indeed now zip native, meaning the --processcanvasapp and the pac canvas unpack processes which operate on PASopa serialization are no longer needed for unpacking and packing.

Workflow if you want to achieve the same as previous functionality (Assuming the .msapp file you are working with uses the latest authoring version) is rename the relevant .msapp file with .zip file ending, unzip as normal (to unpack) then rezip and rename to .msapp (to pack).

if using within an solution unpack and pack as normal.

[marcelbf]

@Dean-Hornibrook
TLDR: Currently, the only way to EDIT a power app (canvas) is through Power Apps Studio or by using the GIT Integration.

Why?
Power Apps stores app (serializes) in JSON files (under the controls folder). They are nor stable across save and load cycles (it means noisy diffs).

PASopa converts these json into fx.yaml. (open source in this repo).

Today, this conversion happens out-of-box, in the new /src folder. This yaml format isn't used to load the entire app yet - but it powers copy and paste (that's why we have yaml snippets now).

When you enable GIT integration, the app will load from YAML files if changes are detected in the repo. There are many reasons for that.

Thanks to the feedback in this repo. we are considering providing an alternative way to pack it back and load from the YAML as well.

Thank you all for engaging!

[guenthi]

Hi @marcelbf ,
As a first step in our process, we've started extracting the source code directly from the .msapp file. However, we've noticed a formatting issue specifically with the OnSelect property of buttons.
In the extracted PA version, the OnSelect code is output as a single line, which removes the original formatting. This differs from the FX version (from Git integration), where the formatting is preserved and matches what we see in App Studio.

Example Comparison:
pa.yaml version
OnSelect: =If(locSelec...
fx.yaml version

OnSelect: |-
           =If(
                locSelecteShow more lines

This discrepancy makes PR reviews difficult and tedious, as it's hard to compare logic changes when formatting is lost.
Is there a known solution or workaround to preserve the original formatting during extraction? Any advice on how we can resolve this on our end would be greatly appreciated.
Thanks in advance!

[guenthi]

@marcelbf - I found a workaround - some code is causing that in pa.yaml version the code is formatted incorrect - I caught one instance of this in PR review - which was trying to introduce faulty code:

here how to reproduce:

if you create a button the app and in the onselect introduce

UpdateContext(
    {
        locIsProcessing: true,
        locSelectedAction: "",
        locOptionSendToClient: "",
        locOptionValidate: ""
    }
);
If(
    locSelectedAction = locOptionSendToClient && CountRows(Blank()) > 0,
    Select(Self);
    ,
    locSelectedAction = locOptionValidate && CountRows(Blank()) > 0,
    Select(Self);
    
);

then check the code and it returns:

- ButtonCanvas1:
    Control: [email protected]
    Properties:
      OnSelect: "=UpdateContext(\n    {\n        locIsProcessing: true,\n        locSelectedAction: \"\",\n        locOptionSendToClient: \"\",\n        locOptionValidate: \"\"\n    }\n);\nIf(\n    locSelectedAction = locOptionSendToClient && CountRows(Blank()) > 0,\n    Select(Self);\n    ,\n    locSelectedAction = locOptionValidate && CountRows(Blank()) > 0,\n    Select(Self);\n    \n);\n"
      X: =477
      Y: =40

I also had another scenario where the code had no issue. I had to split the if-else branch into 2 ifs and then the formatting was as expected.
Is this behavior expected for the source code formatting?
I appreciate your support
regards, Günther

[marcelbf]

@guenthi there's a small bug here on the way we handle the blank line you added in your code snippet - if you remove the formatting will be normal.

but affects the visual only, all the information is there. Thanks for raising it.

[guenthi]

@marcelbf - thanks for your feedback.
As information: the blank line will be added when you use the formatting button in the app-studio, too . (when the "last line" in the if branches are delimted with a semicolon.)

[FlexiGit]

@marcelbf
Using the GIT integration is not an option in many scenarios, as it requires the environment to be a Managed Environment. Which in turn requires ALL PowerApp users in that environment (and probably all downstream environments) to have full premium licenses. On environments where there are hundreds or thousands of users licensed through other products (E3, E5, D365 Fin, etc.), this is not a financially viable solution.
Using the unpack/pack for Canvas Apps is the only way to support a complete and healthy ALM in those scenarios.