Update of version on a dependent assembly plugin package from PAC CLI vs Plugin Registration Tool (PRT)

[imranakram]

Hi,

I've been trying to work out the possibility of implementing a clean ALM process on a plugin package. The idea is that we generate a new version which is assigned to the assembly during the build in the build pipeline.

However, the documentation states:

The name and version of the plug-in package cannot be changed once created. Attempting to do so using an API call results in an error.
https://learn.microsoft.com/en-us/power-apps/developer/data-platform/build-and-package#dependent-assemblies

This restriction is also reflected in the Plugin Registration Tool (PRT), where attempting to update an existing plugin package with a higher version results in an error, as shown below:

However, it appears that updating the contained assembly is allowed as long as the .nupkg has the same version number as the one already in the system. This seems counterintuitive since we would expect the plugin package version to match the version generated by the pipeline for better traceability.

Interestingly, the version update works when using the pac plugin push command, but not when using PRT or the XrmToolBox PRT. This raises the question: why is the update allowed through the pac plugin push command but not via PRT? It would be useful if the version update was supported in PRT so we could easily trace which build produced the plugin package running in the system.

Additionally, one aspect that could be improved is the mandatory --pluginId parameter, which requires a GUID. Wouldn't it be more intuitive and convenient to use the plugin package's text identifier instead?

To summarize:

1. Version Update in PRT: We need the ability to update the version of the plugin package via PRT and SDK, so that developers can adjust the PRT code in XrmToolBox.
2. PowerPlatform Build Task: It would be beneficial to add a PowerPlatform Build task for updating plugins (either assembly or NuGet). This would provide a pipeline task and eliminate the need for custom PowerShell scripts.
3. Improvement to pac plugin push: The pac plugin push command could be improved by allowing the use of the plugin package's unique name instead of the GUID.