Create MSIX Package in Release Pipeline!

Occasional Contributor



I'm new to UWP development and CI/CD pipeline. I'm trying to create MSIX using UWP project.

Below are the scenarios where things work and what I'm looking for.

1. I'm able to generate MSIX package through VS2019 .(Publish->Installed->Wworking)

2. I'm able to generate MSIX package in Azure Build Pipeline using VSBuild@1 task and its arguments.(Installed and Working).


3. Requirement: I'm trying to generate MSIX package in release pipeline through build output(Artifacts) with different env configs. Reason to do that is to generate MSIX to have env specific configurations(dev/qa/prod). As per Azure MSIX packaging tool, I unable to select Project to Build and Manifest File to Update Version .appxmanifest file from build output directory $(Build.ArtifactStagingDirectory. Because it contains only output dlls.


Am I doing this in wrong way? Can you please suggest me the better way to generate MSIX that points to specific env in different stages of release pipeline.


Thank you,


11 Replies

Hi @s_salaria ,


How do specify the env specific configurations for your packages? E.g. whether you modify the manifests, or add a flag when compiling, or something else. Knowing that could help us find a way to do what you need.


If you use the MSIXPackaging task, you will want to point either

  • To the .sln file and .appxmanifest in your sources directory $(Build.SourcesDirectory), to compile into DLLs/EXEs and then create an MSIX (so you skip the VSBuild step); or
  • To a directory with your already compiled DLLs/EXEs and an AppxManifest.xml, to create the MSIX from that without compiling. This could be in your $(Build.BinariesDirectory) if you pointed the VSBuild step to place the files there.

I know that doesn't answer your question, but hopefully helps to move in the right direction.

Thank you @Chacon,


Currently I have only one app.config in project and that project is being referenced in UWP project. Further UWP project is generating MSIX based on that. I don't have any idea how we can use different configs through UWP publishing. 


As per your suggestion I'm looking for second option. Build pipeline will build that project(without UWP project) and release pipelines uses $(Build.BinariesDirectory) or Build Artifacts to generate MSIX with specific env config. please accept my apology if I'm asking too much OOB or uneven.


Thank you and I really appreciate your response.

Hi @Chacon,


Just to add on more about env specific config , I'm using multiple app.config files with env text  in their names e.g I have added one propertygroup in project's .csproj file. Attached is the screenshot for your reference.


By using above approach I'm able to create env specific MSIX in build pipeline(e.g Dev or UAT). What I'm not understanding that how I can proceed further to use that MSIX to point QA configs then later to Prod configs in release pipeline.


Hi @s_salaria,


I believe the app.config file is only copied by the build process to a path similar to <output>.dll.config. In that case, you can have your build pipeline publish the multiple app.config files for each environment, then in the release pipeline copy the appropriate file to the right location before creating the MSIX.


This wouldn't apply if the build process modifies or uses the app.config file in any way (which is not the case AFAIK), because then you would have to set which one to use at build time.

Hi @Chacon,


Thank you for your response. How I can create MSIX package in release pipeline because task "MSIX build and package" look for .sln which is not present in Artifacts(build output). Artifact contains build output(dlls and config file) or msix package(if I include packaging information in vsbuild arguments).

Is there a way to create MSIX in release pipeline? 



In the "MSIX build and package" task, un-select the option "Build solution with MSBuild". Then instead of pointing it to the .sln you will have to point it to the directory containing the contents of the package (like dlls, config and assets) which you already built.

This directory also needs to have an AppxManifest.xml. You could create this by hand, but I believe the VSBuild task should already be creating it for you from the Package.appxmanifest file.

Thank you,


I'm trying the things in same direction as you suggested. Below are the Artifacts copied by build pipeline.



Below are the settings in release pipeline(Packaging).



but I'm getting below error during packing task





@s_salaria ,

Are you trying to create an MSIX package or an MSIX bundle? Sorry, I just assumed you wanted a single package before. You can see a bit more about bundles here: Bundling MSIX packages - MSIX | Microsoft Docs


If you are trying to create a single package, you need to un-select the option "Generate MSIX Bundle". If you select that option, the task will expect a directory containing the multiple .msix packages from which it will create an .msixbundle. If you don't select it, it will expect a directory with binaries, assets and an AppxManifest.xml to create an .msix. The error comes from selecting to produce an MSIX bundle, but using a directory with loose files.

Hi @Chacon,


I've changed all the setting as per your suggestion but still I'm getting error "

MakeAppx : error: You must include a valid app package manifest file named AppxManifest.xml in the source." I'm browsing AppxManifest.xml from artifacts.


Can you take a look in below settings and suggest what I'm doing wrong:

 1. Build task(.yml) 



2. Output in Artifacts. Shell is the actual .csproj referenced in UWP project



3. Release pipeline task settings 



4. Appxmanifest.xml in Artifacts




best response confirmed by s_salaria (Occasional Contributor)

Hi @s_salaria 


The AppxManifest.xml should be in the root of the directory you are packaging. So you need to either move it to the BRMS_Packaging_MSIX\Shell\ directory or point the task to the BRMS_Packaging_MSIX\ directory. (Which probably means that the task doesn't actually need to ask for the path to the manifest, or that if it does it should be using it even if it's not at the root.)


In your manifest file I noticed that there is a reference to a Shell\*.exe file and several Images\*.png files. These files must exist relative to the input directory, so you will want the directory you pass to the task to look something like this:



Thank you @Chacon  for your help. I really appreciate the way you explained everything. Keep up the good work.


Thank you once again.