7

I am using the desktop bridge for a WPF desktop application and am looking to automate the creation of my msix packages during build. I do not want to store any version information in source control.

The WPF project in the solution uses the gitversion msbuild task to automatically infer the version for my executable every time a build is done. Unfortunately, I'm not sure if any such similar mechanism exists for .appxmanifest.

My thinking is that it would be nice to have this nicely integrated with the build process, similar to gitversion, but I haven't been able to find any documentation about what my options are during build or the Create App Packages process.

Perhaps there's some transform step during build that I'm not aware of that can be done to the .appxmanifest? Or maybe there's a way to have the version always reflect the version of the executable being bundled?

(MSDN forums question)

Nico Zhu
  • 32,367
  • 2
  • 15
  • 36
Alexander Trauzzi
  • 7,277
  • 13
  • 68
  • 112
  • If I use visual studio to generate package, it will automatically increase the version number. I'm not sure if the MSBuild do the same thing when you use it to generate package. I suggested to add 'msbuild' tag for your question. – Bite Jul 18 '19 at 14:34
  • Right, but of course incrementing the version implies that you're storing it in source control, which I don't want. Added msbuild, thanks for the suggestion. – Alexander Trauzzi Jul 18 '19 at 14:55
  • Do you mean that you want to match the wpf version with the version in the .appxmanifest file ? – Nico Zhu Jul 19 '19 at 07:13
  • Other way around. I want the `.appxmanifest` to match my WPF version. – Alexander Trauzzi Jul 22 '19 at 12:17

2 Answers2

6

Your should modify the .appxmanifest file in your build pipeline before you create the package. After all, it's just a text-based XML file.

If you are using Azure Pipelines, you could accomsplish this using a Powershell task and a counter variable that gets incremented for each build:

    pool: 
      vmImage: vs2017-win2016
    variables:
      buildPlatform: 'x86'
      buildConfiguration: 'release'
      major: 1
      minor: 0
      build: 0
      revision: $[counter('rev', 0)]
    steps:
    - powershell: |
       [Reflection.Assembly]::LoadWithPartialName("System.Xml.Linq")
       $path = "Msix/Package.appxmanifest"
       $doc = [System.Xml.Linq.XDocument]::Load($path)
       $xName =
         [System.Xml.Linq.XName]
           "{http://schemas.microsoft.com/appx/manifest/foundation/windows10}Identity"
       $doc.Root.Element($xName).Attribute("Version").Value =
         "$(major).$(minor).$(build).$(revision)";
       $doc.Save($path)
      displayName: 'Version Package Manifest'
    +Build, Package and Sign.

Please refer to this MSDN Magazine article for more information and a complete example of how to set up continuous integration (CI), continuous deployment (CD) and automatic updates of sideloaded MSIX packaged WPF applications using Azure Pipelines.

Felix
  • 3,783
  • 5
  • 34
  • 53
mm8
  • 163,881
  • 10
  • 57
  • 88
  • I had to modify the `$xName =` line to `$xName = System.Xml.Linq.XName]::Get(http://schemas.microsoft.com/appx/manifest/foundation/windows10}Identity")`. Not sure if that's specific to my setup. – Felix Nov 22 '21 at 23:22
2

You must update the manifest before packaging. Check out this sample including a powershell script to poke the xml with the gitversion provided. https://github.com/microsoft/devops-for-windows-apps/blob/master/azure-pipelines.yml#L72

rido
  • 1,202
  • 1
  • 9
  • 13