YOU’RE READING
MSIX Packaging Fundamentals
by Tim Mangan, Bogdan Mitrache & Kevin Kaminski
Download ebookAlso check MSI Packaging Training Book
MSIX Common Packaging Tutorials
In this chapter we provide answers to some topics we are frequently asked about but have not yet covered.
How To: Setting up a recapture VM
The recapturing of an application installation needs to be performed in a special well-prepared environment, which is typically a virtual machine (VM) with a snapshot. The VM is always reverted to this snapshot prior to any recapture, with the purpose of ensuring that it is a well-known environment.
The VM should be as clean as possible. This is important because application installers will detect whether dependencies already exist on a machine, so specific components may be left out of the package and not reapplied. Any software added to the VM beyond the operating system could potentially add dependencies. Even though recaptured packages may work fine on initial test systems (with dependencies) - as time passes, it is possible for a package to break when landing on a system without that dependency. Current practices usually try to keep this image to hold just the OS and the required repackaging tools.
The vendors of these tools generally limit their dependencies.
Often, organizations require anti-malware software to be present on all systems. And unfortunately, anti-malware software adds many dependencies that change every year. So, it is better to use the anti-malware software that is already built into the OS while packaging, then use your preferred vendor scanning tool to detect anything that shouldn't be in the future packages.
Additionally, the OS should be tuned to reduce background activity that could lead to capturing unnecessary (or dangerous) components. This varies depending on the packaging purpose and the versions of the OS, and often, it includes the following steps:
- Turning off unnecessary services, such as Windows Updates or Windows Search, as well as other services that you will not use, (i.e. bluetooth).
- Not joining the OS to the domain, or exempting it from the Group Policy.
- Turning off Windows Apps updates.
- Disabling anti-malware definition updates.
- Pending system changes
Some repackaging tools, like Advanced Installer (and others), automatically check for these rules and assist you in enforcing them - while also managing the VM snapshot states automatically for each new package.
How Tos - Common packaging scenarios
Installing a font
Starting with the 2004 version of the Operating System, MSIX packages may now include fonts for use on the system the application package is deployed to. These changes are supported by changes to the AppXManifest schemas as part of the Uap4 schema extensions.
Deploying fonts, or any other system resource, with an MSIX package, requires entries in the AppxManifest.xml for each of the fonts. Even when you have a recaptured and fully installed font in the package, the font will not be available to use by any application without a declaration in the AppXManifest file.
Installing a package that contains a font declaration instructs the OS to register the font using the Windows Font Manager, making it available for any application installed on the system.
Removing that package will remove the font. Thanks to single instance storage, if the same font is added by two different packages, this is correctly handled.
For example, to add a font named “Radiant”, the font file must be present in the package, and the following declaration has to be included in the manifest as part of one of the “Application” elements:
<Applications>
<Application Id=...............................>
<Extensions>
<uap4:Extension Category="windows.sharedFonts">
<uap4:SharedFonts>
<uap4:Font File="VFS\Fonts\Radiant.ttf"/>
</uap4:SharedFonts>
</uap4:Extension>
</Extensions>
</Application>
</Applications>Although the fonts are added on the basis of the package, you must still add this within one, and only one, of the Application elements. It does not matter which application you apply the font references to.
Currently, the MSIX Packaging tool ignores captured fonts contained in the package. When using this tool, PsfTooling can detect and provide the syntax that you would need to manually add it to the Manifest.
With Advanced Installer Express, this can be done in just a couple of clicks. Just go to Declarations view and configure your font, this will ensure your package manifest is correctly generated.
For full details and a tutorial video, check Advanced Installer Blog - Installing Fonts in MSIX Package.
“Path” Environment Variable replacement
The most common scenario for using an environment variable is when an application wants its main executable path to be added to the “Path” environment variable.
A newer replacement technique, which is also used to help a process find folders containing DLLs, is the App Paths registration in the Windows Registry. These techniques allow a process to be started or DLLs to be loaded without direct knowledge of the folder they are in.
MSIX packages have no direct support for any environment variables, and the App Paths registration is not recognized either. But for scenarios like the one above, to help with the DLLs, the Package Support Framework has the DynamicLibraryFixup. There is a new EnvVarsFixup to support environment variables when inside the container, but this might not be appropriate for the Path variable changes.
Fortunately, there is another predefined solution to allow finding an EXE by name only introduced by the MSIX Manifest. You can also achieve this by declaring an execution alias for the application, in the AppxManifest.xml file.
<Applications>
<Application EntryPoint="Windows.FullTrustApplication" Executable="AI_STUBS\AiStub.exe" Id="EnvironmentVariables">
<Extensions>
<uap5:Extension Category="windows.appExecutionAlias" EntryPoint="Windows.FullTrustApplication" Executable="HelloWorld.exe">
<uap5:AppExecutionAlias>
<uap5:ExecutionAlias Alias="HelloWorld.exe" />
</uap5:AppExecutionAlias>
</uap5:Extension>
</Extensions>
</Application>
</Applications>If you're using the Microsoft MSIX Packaging tool, this would be something that you will need to manually add to the manifest. However, if you also need the PSF and are using PsfTooling then PsfTooling will take care of this for you automatically by different means.
With Advanced Installer Express, this can be done in a few clicks. After adding the executable in your package, you can simply go to Declarations view in Advanced Installer and declare your execution alias.
For full details, check out this article Advanced Installer Blog - MSIX Environment Variables
allowElevation capability
If your Win32 application needs to ask for user elevation upon launch, then you need to set the allowElevation capability in your AppxManifest.xml.
<Capabilities> <rescap:Capability Name="runFullTrust"> <rescap:Capability Name="allowElevation"> <Capabilities>
Setting this flag alone in the package manifest will not enable your application to request for elevation. As its name implies, this flag only allows your application to request an elevation. How does an application request elevation rights? It does so by setting the execution level to “requireAdministrator” from the app’s main EXE manifest.
If your application does not have this value set in its EXE manifest, then the “allowElevation” capability will simply be ignored and the application will not try to automatically elevate when the user launches it. The user can still manually run it as an admin by right clicking the application and selecting “Run as administrator‘.
You can find more insights on this article: Advanced Installer Blog - How to set AllowElevation flag for MSIX packages
Note: Starting with Windows 10 20H1 this capability seems to no longer be required for sideloaded applications.
Startup Applications
Registry entries under “Run” key or shortcuts placed in the “Startup” folder are no longer a viable solution for MSIX packaged applications.
To configure an application to launch at startup, you need to define a “StartupTask” in the package AppxManifest.xml, as shown below.
<Applications>
<Application Id="TheApp" Executable="TheApp.exe"
EntryPoint="Windows.FullTrustApplication">
<Extensions>
<desktop:Extension
Category="windows.startupTask"
Executable="VFS\TheApp.exe"
EntryPoint="Windows.FullTrustApplication"/>
<desktop:StartupTask TaskId="TheApp"
Enabled="true" DisplayName="The App"/>
</Extensions>
</Application>
</Applications>Get more details here: Advanced Installer Blog - The new way of dealing with Startup Application in your MSIX package
Disabling Files and Registry Virtualization
The MSIX container provides default virtualization for any files found under the VFS folder and to any registry entry found under a registry path included in the registry.dat hive from the MSIX package.
To disable the registry and file redirections, the following properties must be added in the AppxManifest.xml:
- desktop6:RegistryWriteVirtualization: Indicates whether virtualization for the registry is enabled for the desktop application.
- desktop6:FileSystemWriteVirtualization: Indicates whether virtualization for the file system is enabled for the desktop application.
The above properties should be included inside the Properties element of the manifest. For example:
<Properties> <desktop6:FileSystemWriteVirtualization>disabled</desktop6:FileSystemWriteVirtualization> <desktop6:RegistryWriteVirtualization>disabled</ desktop6:RegistryWriteVirtualization> </Properties>
These two capabilities appear to be intended only for debugging purposes and are unlikely to be useful for production packages.
Additional details on these settings may be found at Advanced Installer - MSIX Disable Registry File Redirection.
YOU’RE READING
MSIX Packaging Fundamentals
by Tim Mangan, Bogdan Mitrache & Kevin Kaminski
Download ebookAlso check MSI Packaging Training Book