Hi All, I'm thrilled that Microsoft is adding something to support licensing ISV apps distributed through AppSource. That being said, in its current state it's pretty confusing and the documentation does not provide much clarity on the what or how of this feature.
As an ISV, here's my understanding of this feature in its current form:
We have an existing offer in AppSource. It has a model-driven app and no code components. We have full ALM automation built out in Azure DevOps and everything runs pretty smoothly. We're small so making changes in an unmanaged environment and then committing to repo works for us. All deployments are automated. The only time we mess with Visual Studio is to package for AppSource. We never open command line tools.
Here's a little recap of my experience attempting to implement and evaluate this:
Here's where things slowed down. The first step says "Clone existing solution". In our world, that means go into the unmanaged Power Apps maker environment, select the solution and click "Clone a patch" or "Clone solution". This is not what they mean and it's confusing.
Looking forward to this being more supportable. As of right now, it doesn't seem to be compatible with the ALM tools in Azure DevOps that we rely on.
ServicePlans.xml content:
<?xml version="1.0" encoding="utf-8"?>
<serviceplans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<serviceplan name="[SERVICE_PLAN_ID]">
<accessmode>4</accessmode>
<iscustomizable>0</iscustomizable>
<displayname>[SERVICE_PLAN_NAME]</displayname>
<moreinfourl>[YOUR_ISV_PLAN_INFO_LINK]</moreinfourl>
</serviceplan>
</serviceplans>
ServicePlanAppModules.xml content:
<?xml version="1.0" encoding="utf-8"?>
<serviceplanappmodulesset xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<serviceplanappmodules>
<iscustomizable>0</iscustomizable>
<appmoduleid>
<uniquename>[MODEL_APP_COMPONENT_NAME]</uniquename>
</appmoduleid>
<serviceplanid>
<name>[SERVICE_PLAN_ID]</name>
</serviceplanid>
</serviceplanappmodules>
</serviceplanappmodulesset>
Documentation references:
@Helpful- That XML is actually in the customizations.xml after you package the solution folder using the Solution Packager tool.
Thanks, @rajyraman. Our solution is built using Power Platform Build Tools in Azure DevOps and the XML shown above does not appear in the Customizations file.
I thought the build tools used Solution Packager behind the scenes so would assume the same behavior as if we built with SolutionPackager, but maybe that’s a bad assumption.
I’ll test this tomorrow.
@Helpful- Check the version of Solution Packager being used from the AzDO logs. The one I use on the local machine is 9.1.1.2.
Thanks, @rajyraman. Sure enough, it looks like Power Apps Build Tools is using Version 9.1.0.67.
We packaged with command line and are now seeing the service plan xml nodes populated in Customizations.xml.
I guess we'll wait for the tooling to catch-up. I recall the team that was working on those was getting a fair amount of investment a year ago, but perhaps priorities have shifted.
Hi @Helpful,
Thanks for the elaborate feedback... my experience was almost exactly the same, as I stuck also to pack the managed solution, then eventually found it in the SolutionPackager Command Line.
now I submitted my package for publish in AppSource, and waiting for certification.
@Helpful - As an ISV, we have a very similar dev process to you, using Azure DevOps with automated deployments to customer-specific dev environments and production environments. Azure DevOps build tools do not currently support including the LMS as you point out, although we've communicated the need to the team responsible for the build tools.
The PAC CLI does nothing other than generate the xml from the csv mapping files, and then adds it to the end of your managed solution. The folders with the csv files don't need to be in the final solution. Once you have that xml generated, you can copy it into the managed solution directly. When we first got started we didn't use the PAC CLI at all and just created the service plans and mapping directly in xml, and then added to our managed solution.
Editing service plan information is currently not supported with an unmanaged solution for the obvious security reasons (though this may change at some point) - this means that you have to add it every time you export a managed solution from your dev environment. We added a powershell step in our devops pipeline to add the xml to the managed solution when we pull from core dev prior to deploying the managed solutions to customer-specific dev and production environments.
Thanks @Captjoemcd ,
Here's a snip of powershell to get others started. The two files it uses are the customizations.xml file that is in the "Other" folder when you unpack the solution. (I unpacked it into a folder called "tempforpacking" of course.) The license.xml file is just the license specific section of the xml that the pac cli generates. I haven't added checking to ensure the nodes were added yet, but that should be straight forward.
Hi Folks,
I am the PM that worked adding the licensing capability. I would really like to understand the paradigm a little bit better on how you want licensing to be part of the CI/CD process. I did have an exchange with Jeff in a seperate thread. But I would like to understand the broader sentiment and the CI/CD workflow in question.
When you respond, please @ me directly so that I can get notified.
Hi @kartikka, thanks for the opportunity to provide feedback. I will speak on behalf of our setup and am curious to hear the perspective of others.
Please see attached image. To make this work:
We have the approach above implemented today, but some of Step 4's tasks could be cleaned-up to use Build Tools instead of PowerShell.
User | Count |
---|---|
3 | |
2 | |
2 | |
1 | |
1 |