Adding licensing information to an existing solution

[Helpful]

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:

• It DOES:
  • Restrict AppSource deployment of model-driven apps to only those tenants that are registered by the ISV in Partner Center
  • Allow customers to assign licenses to individual users from within their own M365 Admin Center
  • Once deployed, restrict access of ISV model-driven apps to users that are assigned a license
• It DOES NOT:
  • Allow ISVs to add licensing to existing AppSource offers
  • Allow ISVs to add licensing to packages built with current Power Apps Build Tools (v1.0.23)
  • Allow import of unmanaged solutions that include service plans
  • Allow customers to purchase licenses at the time of clicking "Get it Now"

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:

• Copy an existing AppSource offer - this is mostly cut/paste exercise, however, it will mean the back/forth of approvals with AppSource... content, tech, and co-sell material. Also updating any marketing links to the new offer if published.
  • Add a plan to the new offer. Note the "Plan ID", you'll need it later.
• Go to the solution in my unmanaged environment and add a "Service Plan" component - just kidding we read the steps before that: Add licensing information to your solution

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.

• The documentation is referring to command line tools that we don't have (Power Apps CLI) - get those.
• Using the clone command of the Power Apps CLI does not appear to make much sense for us since we already store our unpacked, unmanaged solution files in ADO. So I download those an unzip them locally.
• Create licensing files - two CSV files. Do not get confused by file names in the screenshots - they actually need to be ".csv" files.
• Add the licensing information to the solution using the specified Power Apps CLI command.
  • Take a look at what that command did. Comparing the modified solution files with an old set for reference, we can see that it:
    • added a folder called "ServicePlans" (right between Roles and WebResources).
    • added two Xml files (documented below) to the new folder, populated with the values from your .CSV files.
    • added two empty nodes "<serviceplans /><serviceplanappmodulesset />" to the Customizations.xml file in the "Other" folder.
  • Had I known they needed a folder with a specific name and two files with specific names I could have done that without the extra steps.
• Build the solution. Here's where we get stuck. The documentation for this is particularly confusing: Create a managed solution for your app
  • We have DevOps automation to build solutions so we branch our unmanaged solution, apply the changes (noted above) in the repo and use our existing automation to build a managed package.
  • Open the resulting ZIP file and the empty nodes are now represented in the Customizations.xml file, however, the two files are nowhere to be found in either the Managed or Unmanaged solution package.
    • Is there some other tool we're supposed to use to ensure those files are picked up?
  • With input from @rajyraman, we discovered that the Package Solution task of the current version of the Power Apps Build Tools is not using the latest version of SolutionPackager and, therefore, does not generate the service plan content in Customzations.xml.
  • Use SolutionPackager on command line as workaround to package both Unmanaged and Managed solutions. Confirmed the service plan XML is incorporated into Customizations.xml.
• Tested import of unmanaged solution that has service plan information to a clean environment. This fails with the following message: "Solution "ISV Solution" failed to import: ServicePlanAppModules data can only be changed by managed solution import".
• Package for new AppSource offer and evaluate - Update below. WE'RE PAUSING HERE FOR NOW. Hoping we see updates that make it more manageable with our existing ALM setup.

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:

• https://docs.microsoft.com/en-us/azure/marketplace/third-party-license
• https://docs.microsoft.com/en-us/azure/marketplace/dynamics-365-customer-engage-plans
• https://docs.microsoft.com/en-us/powerapps/developer/data-platform/appendix-add-license-information-...

[malkhawaja]

Hi @JeffCarma @Helpful @kartikka ,

I would like to thank @JeffCarma  for the PowerShell snippet, which I implemented in a DevOps build pipeline, and now I do not have to manually add the license metadata to the solution.

If anyone is interested of the steps, I will be happy to explain it.

@kartikka , we would love to see a Microsoft Power Platform Build Tools task in which we can add the license metadata to a managed solution, which will automate the whole process.

Cheers,

Mohammad

 

[JeffCarma]

Thanks @malkhawaja, I'm glad you found it helpful. In my earlier post, I said I was going to add a double check to ensure the new xml nodes made it. Here is that if you'd like to use it.

#Check to make sure the node was actually added

Write-Host "checking for new nodes existence"

[xml] $mod = Get-Content '.\tempforpacking\Other\Customizations.xml'

$displayName = $mod.SelectSingleNode("ImportExportXml/serviceplans/serviceplan/displayname").InnerText

if ($displayName -eq $null){

    throw "Display name not found in serviceplans xml node!"

    }

[malkhawaja]

Hi,

I am moving along the experience of the ISV License management, and until now I only added one plan (let's call it TestApp Basic) for one app, and now I will start adding multiple plans, which means according to documentation, I should create multiple apps (one app for each plan), but in my case (which is the case of many others I think) I am adding some extra features (e.g.: extra tables and BPFs) so if I should create an extra app (lets call it TestApp Pro), and supposing I have a customer who wants to go with the "Pro" version, they will end up with 2 model driven apps in their environment (1 basic, and 1 Pro), the basic one will be redundant now,  right? what do you think we should do to the redundant app?

[Captjoemcd]

The way we're thinking about it is we'd have the basic app and the pro app and map licenses 1:1 to the apps, so a Pro user would have access to the Pro app but not the basic app, and the Basic user would see the basic app but not the pro app.  System admins will see both, but users would only see one. 

Further down the line, entity-level license permissions will be available, in which case having a single app with multiple levels of license will make more sense.