This isn’t optimal at all since it’s impossible to open those files. If you would try you get the following message.
In addition to that the msapp file (which is basically a zip-file) obscures the changes. We can’t see what was changed and when.
Fortunately, Microsoft released an experimental feature on January 14th, the Power Apps Solution Packager. Here is the related blog post. The Power Apps Solution Packager or PASopa is exactly fixing the problem I described earlier. It can pack and unpack msapp-files/Canvas Apps.
The PASopa is still experimental. So if you use it you do that on your own risk.
Since it is an experimental feature it is not included in the mentioned “Unpack Solution” step of the Power Apps Build Tools. It will be included eventually but isn’t just yet.
As mentioned the PASopa is experimental. That is also the reason why there is no direct download of the exe-file you’ll need to run the tool. We will only store the PASopa.exe (and all the needed dependencies) in our repository.
There are different ways of achieving this. One could store the source code of PASopa in the own repository and creating the exe whenever the pipeline runs. This will increase the runtime though. Another approach would be to have a separated pipeline that creates the exe and use this pipeline as the input to all the other pipelines. The last approach I could think of is to fetch it from GitHub in the pipeline to always have the latest and greatest.
I just choose the one where I store the exe directly. To make the build quicker and the blog post easier to understand.
Generating the PASopa.exe
In the “Distribution” section of the blog post they describe the process on creating the exe file.
The first part refers to our PASopa.exe file which is located in the Tools folder.
The second part, -unpack, defines what the PASopa should do. In our case unpack the file
The last part points to the msapp file to handle.
There is a third optional parameter which would define the output path. I choose to store the extracted Canvas App in the same folder structure for 2 main reasons
Be clear which Canvas App is related to which Solution
Make it possible to do changes directly in the repo and still be able to pack a working solution in the end
You could choose to store the files in a different folder if you only use the change tracking features of your repo (see LinkedIn comment about it).
Please notice that I use a custom pipeline variable called “SolutionName” to define the solution name in a dynamic way.
Unfortunately, the PASopa only handles a single msapp-file at the time at the moment. If you have several Canvas Apps in your solution you would like to run this task several times (or bundle it in a Task group).
After you run the changed pipeline you will have the unpacked Canvas App in your source control and can use all the good stuff that comes with it.
When the PASopa is in your repo it is rather easy to unpack canvas apps in a pipeline. I hope this functionality gets included in the standard “Unpack Solution” step soon to get rid of the workaround described in this post.
Now if you follow the process I describe in the mentioned blog post you would pack the solution from source control and “convert” it to a managed solution via a Build environment. To get that working you have to pack the Canvas App to a msapp-file again. This is basically done exactly the same just that you say the script to pack the canvas app and then deleting the unpacked stuff.
Shoutout to Scott Durow for taking your time discussing and confirming my approach!
I hope this article helped you. Feel free to contact me if you have any questions. I am happy to help.
This is just 1 of 58 articles. You can browse through all of them by going to the main page. Another possibility is to view the categories page to find more related content. You can also subscribe and get new blog posts emailed to you directly.
Privacy & Cookies Policy
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.