Forum Discussion
Create MSIX Package in Release Pipeline!
Hello,
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,
Shub
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:
\ AppxManifest.xml Shell\ BRMSv2.exe ... Images\ StoreLogo.png ...
ChaconMicrosoft
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 app.dev.config. 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.
- Chacon
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.
