I am currently working on a large enterprise windows store application. The customer came up with an interesting requirement the other week. They wanted to be able to have multiple versions of the same store application deployed on the same device, so for example they could be running the current production version whilst also previewing the latest drop from a sprint.
Traditionally this had not been a problem with traditional client applications. However with the way windows store application work this was not as straight forward, normally you can only side load a single instance of a windows store application.
After putting some thought into this requirement and considering an option that would give the least impact to such things as automated build, I came up with the following solution.
Everything that determines the capabilities and general information on the Windows store application is stored in the Package.appxmanifest. By default this opens with a GUI interface in VS2013, underneath this interface it is just an XML file. I decided to look at what the raw XML shows.
I experimented with the XML found and found that if I simply changed the Identity name and gave it a new Guid I could have multiple versions of the same application running. On discovering this I decided that a post build event to switch the appxmanfest based on a solution configuration could do the job. I started by copying the appxmanifest in my store application project and prefixing it with the word ‘dev’ in the file name. Visual studio will happily let you do this until you try to compile the project at which point you get an error stating that a store application project cannot contain 2 appx manifests.
To get around this error I created an xml file instead and called it Package.Dev.xml within the Windows store application project. Next I copied the XML from the appxmanifest and pasted it into Package.Dev.xml
To make it easier to identify instances it is probably best to also change the name and description of the application, even maybe go as far as changing the icon to distinguish versions.
Once you have done this right click the Windows store application project and select properties. Go to Build Events. Add the following xcopy command to the pre-build event command line
if “Dev”==”$(ConfigurationName)” xcopy “$(ProjectDir)Package.Dev.xml” “$(ProjectDir)Package.appxmanifest” /R /Y
The command has a conditional based on the configuration mode the project is built under. For this command to work you will need to create a new configuration and call it Dev in this case.
Create store applications with the debug configuration and then with the dev configuration. You should now be able to install both packages and have them both sideloaded.
Note if you just right click and deploy from VS it overwrote the apps for me, but if you right click your application project and create a windows store package and then run Add-AppDevPackage.ps1 it deploys the applications side by side.
If you want you can continue to add further xml files and append the to the list of pre build events to allow further multi side load instances
For our automated builds all I needed to do was specify the different configurations to build the corresponding app packages.