Tech Community Live: Windows edition
Jun 05 2024, 07:30 AM - 11:30 AM (PDT)
Microsoft Tech Community

Single MSIX Package for Different Environments

Copper Contributor
Hi,
 
We have a requirement in MSIX where we have to convert the Appv5.1 package into a single MSIX package for four different environment (pre, prod, uat, dev) where the only difference for all the environments is that they copy a config file into the bubble based on the environment.
 
Can that be achieved in MSIX in single package?
 
The below is the bat script which is used to copy the file according to the environment. 
 
@echo Off
echo Loading environment files
 
if "%1"=="DEV" set EnvFile=UserInterface.exe.config-dev
if "%1"=="PRE" set EnvFile=UserInterface.exe.config-pre
if "%1"=="UAT" set EnvFile=UserInterface.exe.config-UAT
if "%1"=="PRD" set EnvFile=UserInterface.exe.config-prd
 
echo f | xcopy \\Folder\files\%EnvFile% "C:\ProgramData\Microsoft\AppV\Client\Integration\Root\Data Loader\UserInterface.exe.config" /y
 
 
PS: These files are present in a share location from there the script copies the files into the bubble. 
 
 
8 Replies

Yes, this can be done in MSIX, just differently.

 

I assume from the example that you used 4 different shortcuts calling the script with the different cmd line arguments.

 

This directly maps in MSIX, however Microsoft tooling will not do it right and you must do a bit of manual editing, especially if you want to future-proof the package name.  TMEditX would probably fix that for you automatically.  Similarly, since you also tagged Bogdan, AdvancedInstaller can probably help you too. 

 

We also often do something similar using a single shortcut to the program. But use PsfLauncher to run a single script, with arguments for the package root folder ( offset to get the source file) and WritablepackageRoot folder (offset to get destination). Probably need the MfrFixup of the PSF too. Your script can still be on a network share, but needs to be Powershell. The PS script needs to dynamically decide what environment the user is in, replacing your if on the shortcut argument value.

Thank you for your response. Will try and let you know if it works for us.
If you are looking for another approach to find a solution for this problem, please take a look at the MSIX Helper.

https://github.com/FvGelderen/AutoHotKey/tree/MSIX-Helper/MSIX%20Helper%201.2

I just released version 1.2 and this will also support if/else statements for the script sections. The documentation (pdf) can be found in the bin folder with the MSIX Helper executables (32 and 64-bit).

Any feedback is appreciated.
is this the same as the Tim Mangan psflauncher.exe. Only here it works with ini files instead of json files?

@TIMOTHY MANGAN

Can you please provide the steps to apply the mfr fixup?  

@Pollewops Regarding Ferry's tool, It looks like a exe launcher controlled by an ini file.  Like by old ScriptLauncher program we used for App-V, it is simple to use but does not lend itself to the dll injections required if you need PSF injections.  You would have to manually apply it to the package, including changing out the shortcuts.

@Abhi211 The request sounds more complicated than can be explained here, but I can provide an overview of your options. 

 

One way is to use the free PsfTooling during the packaging process.  While in the installation phase of the Microsoft MSIX Packaging Tool you would install the program and copy down any scripts, and then launch PsfTooling.  The GUI provides the ability to define the script to be run, including any arguments.  Check PSFLauncher documentationHome · TimMangan/MSIX-PackageSupportFramework Wiki (github.com)  for variables to use in the arguments that evaluate to the Package Folder and Redirected Package Folder that you'll probably need.  In the GUI you'd just click the checkbox to add in the MfrFixup while there.  There is some text that will be displayed when you add the MfrFixup in ILV-aware more that must be copied to your clipboard.  After you close PsfTooling and return to the Microsoft packager, you complete the packaging process short of saving the package.  You must then export and edit the AppXManifest file to copy that text into the manifest as shown in the XML comments that you copied.

 

Alternatively, TMEditX (a licensed tool) can be used to perform these actions on a post-packaging editing session.  The GUIs for the two are very similar for defining the script and enabling MFrFixup, but TMEditX will fix up the AppXManifest for you automatically.

Like Tim already mentioned, the MSIX Helper tool is designed as an alternative for the PSFLauncher for adding basic script tasks before and after the program is started. For now, there is no dll injecting possible to manipulate the behaviour of the application itself. However, it is for example possible to copy the program files outside the original (non writable) MSIX package location (like the %USERPROFILE% or %TEMP% location) when starting the application so the program will run from a writable location if needed. Keep in mind that although the program can be started using the MSIX entry points from the start menu or filetype associations, registry information and the VFS inside the MSIX package will not be accessible when the application is started outside the MSIX container. I have used this for the KeePass application to make this work when it is delivered as an MSIX package. KeePass is known not to work when the program is started from the MSIX container location (C:\Program Files\WindowsApps) but will work perfectly when it is (temporarily) copied to (and started from) a location like %TEMP% or %USERPROFILE%. This can be done using the basic script actions as described in the MSIX Helper documentation.