cancel
Showing results for 
Search instead for 
Did you mean: 
Reply
Dlabar
MVP

ALM - How to Increment Plugin Version in Azure DevOps

So many questions!  At the 10k foot view I think I want to have my revision number of my plugin assembly be auto-incremented by 1, and I want to be able to then injected that into my extracted solution for packing and importing into the build environment.  How do I do this?

 

Details:

  1. I have a pipeline that builds my plugin on any code change that would affect it.
    1. How do I get this pipeline to auto increment the revision number and then check it in when it successfully builds and passes the tests?
    2. How do I share this file with later pipelines?  Publish the plugin assembly as a pipeline artifact?
  2. I have another pipeline that exports and extracts the solution out of Dev and checks that into Git before building and pushing to the Build environment.
    1. Should this pipeline be split into two, one for exporting the solution, injecting the plugin, and checking into Git, and another for packing and pushing to the build, before exporting out the managed solution?
    2. When looking at the {plugin}.data.xml file in the extract, it lists the assembly version.  How do I update this as well?  Do I perhaps not need to?

 

And if I'm doing something that seems wrong, or more complicated than it should, let me know.  Normally I never increment the plugin version, but I believe I've heard that this could cause issues when not doing so with managed solutions.  Maybe I shouldn't be doing this at all?

1 ACCEPTED SOLUTION

Accepted Solutions

Hi Daryl,

I don't find there is a need to check in any changes as part of build pipeline.


The Build Pipeline runs like this:

  1. Checkout branch
  2. Run PowerShell Script to:
    1. Update the Plugin Assembly Versions with the Build Version
    2. Update the PCF Manifest Files with the Build Version
    3. Update the Solution.Xml with the Build Version
  3. Build Plugin Solution
  4. Build TypeScript Projects
  5. Copy Plugin Assemblies to the package folder
  6. Copy JavaScript output to the package folder
  7. Package Solution (solution_unmanaged.zip)
  8. Import to Build Server
  9. Export as managed
  10. Publish Build Artefacts (solution_managed.zip)

The PowerShell I use is similar to this - https://docs.microsoft.com/en-us/azure/devops/pipelines/scripts/powershell?view=azure-devops&tabs=ya...

 

Only increment the Assembly Version because if you increment the File Version then your plugin registration steps (*.data.xml files) will no longer point to the correct version.

 

Hope this helps

View solution in original post

3 REPLIES 3

Hi Daryl,

I don't find there is a need to check in any changes as part of build pipeline.


The Build Pipeline runs like this:

  1. Checkout branch
  2. Run PowerShell Script to:
    1. Update the Plugin Assembly Versions with the Build Version
    2. Update the PCF Manifest Files with the Build Version
    3. Update the Solution.Xml with the Build Version
  3. Build Plugin Solution
  4. Build TypeScript Projects
  5. Copy Plugin Assemblies to the package folder
  6. Copy JavaScript output to the package folder
  7. Package Solution (solution_unmanaged.zip)
  8. Import to Build Server
  9. Export as managed
  10. Publish Build Artefacts (solution_managed.zip)

The PowerShell I use is similar to this - https://docs.microsoft.com/en-us/azure/devops/pipelines/scripts/powershell?view=azure-devops&tabs=ya...

 

Only increment the Assembly Version because if you increment the File Version then your plugin registration steps (*.data.xml files) will no longer point to the correct version.

 

Hope this helps

View solution in original post

  1. So you never check in the assembly version in the .proj file.  Makes sense I guess!
  2. Do you have a pipeline for immediately testing changes if something has been updated as well, like I've listed, but with no artifacts, just to let devs know they've screwed up?
  3. There is no need to update the file version of the dll then, and therefore no need to update the *.data.xml file?
  4. Is the Solution.Xml update the <Version> in the ImportExportXml-->SolutionManifest-->Version Xml Attributes?

  1. Yes
  2. Yes - other pipelines for gated check-ins (build, package & test)
  3. Yes - only update the build/revision - not the major/minor - otherwise you'll have a side-by-side version that will have a different *.data.xml registration https://docs.microsoft.com/en-us/powerapps/developer/data-platform/register-plug-in#assembly-version...
  4. Yes - The Other/Solution.xml file when unpacked. Update the ImportExportXml/SolutionManifest/Version element. See https://gist.github.com/scottdurow/fe844a012c388f2e3e8bafdf4a2d897d 

 

Helpful resources

Announcements
PA User Group

Welcome to the User Group Public Preview

Check out new user group experience and if you are a leader please create your group

secondImage

Demo Extravaganza is Back!

We are excited to announce that Demo Extravaganza for 2021 has started!

MBAS on Demand

Microsoft Business Applications Summit sessions

On-demand access to all the great content presented by the product teams and community members! #MSBizAppsSummit #CommunityRocks

Power Apps June 2021

June Power Apps Community Call

Did you miss the call? Check out the recording here!

Users online (12,869)