Package Files and VFS

Package files may exist either under the root of the package (next to the AppXManifest.xml file referenced earlier) as well as in numerous subfolders that may be created, or under a special subfolder named VFS or Virtual File System.

We will be covering both of these notions within the current section.

Package “Root” folder

Although you may be tempted to put files under the root folder as it gives you the impression that it mimics the Win32 style of installing into the Program Files folder, in practice all files will be placed under the “Program Files\WindowsApps” folder. VFS files are just written to VFS subfolders, which allow for layer merging opportunities with native files and other packages.

For example: when the package contains configuration files that an Enterprise IT Pro might want to override by using a Modification Package with updated versions of those files. This scenario will require the developer to use VFS pathing, at least for those files.

Files under the package root folder (and subfolders other than VFS) are normally not writable without using the Package Support Framework to include additional redirection capabilities. However, on OS 2004 and later, there is a new manifest entry in the UAP10 schema called “InstalledLocationVirtualization”. When specified, this manifest instructs the runtime to perform the same action that the PSF FileRedirectionFixup would have taken to allow writes.

Virtual File System (VFS)

For compatibility purposes, when repackaging traditional apps, we often prefer to place the files under the VFS tree.

Inside this VFS folder, there may be additional specially named folders that represent original system locations. It might be convenient to think of them as variables similar to the %Home% environment variable, or KnownFolderIds.

The VFS allows the traditional Win32 application to either make requests to the actual installed location, or (when inside the VFS folder) allow the application to access its own resources without requiring any code changes. When it comes to application files access, the redirection kicks in automatically when the application is trying to access files from the equivalent location on the end-user’s system. The support provided may vary depending on the nature of the file operation, and the location of the file.

When the application running inside the container attempts to find or read a file under the known path, the system will automatically check the redirected package VFS location first, and then (if necessary) check the location requested by the application.

While Read operations should work without any problems (except for AppData and LocalAppData, as noted below), Write and other operations will lead to many application failures. This is expected unless Package Support Framework fixups are applied to the program to solve the issue.

Please note that Read, Write, and other operations to files and folders that are not part of the package, or VFS mapping, are not controlled by the container and are allowed as long as the user has permission to perform the operation requested. For example, as long as the package does not have a VFS\Documents folder in it, any attempt to Read or Write files to the user’s Documents folder will be handled externally and those files will be automatically visible to other applications.

These details of VFS support may vary depending on the folder, and possibly the OS version. Many (but not all) of the VFS folders supported are documented by Microsoft here.

Be aware that this document hasn't been updated since the previous Desktop Bridge technology, so some details are no longer applicable.

Developers with access to source code should consider that it is highly recommended that you use API calls for retrieving the location of standard folders rather than “hard-coding” paths in your software. Both Environment variables and KnownFolderID APIs are available for this purpose, and will help make the application more portable. For example, for AppData folder paths, you might use something like this:

//local app data
string localPath = Environment.GetFolderPath
      (Environment.SpecialFolder.LocalApplicationData);

//roaming app data
string roamingPath = Environment.GetFolderPath
      (Environment.SpecialFolder.ApplicationData);

The most important VFS folders are listed here:

ProgramFilesX86 and ProgramFilesX64

On a 64-bit Windows 10 system, the known paths:

C:\Program Files\ 
C:\Program Files (x86)\

Will map to paths looking like these:

C:\Program Files\WindowsApps\<AppName>\VFS\ProgramFilesX64\
C:\ProgramFiles\WindowsApps\<AppName>\VFS\ProgramFilesX86\

Documents

Maps to the users Documents folder.

Windows

Maps from C:\Windows

Although some sub-folders under this system folder have separate mappings, this VFS reference is used for all other references. For example, DotNet components added to the global assembly cache appear under the VFS\Windows\Assembly folder.

Fonts

Maps from C:\Windows\Fonts

Systemx86

Maps from C:\Windows\System32 on 32 bit systems.

Maps from C:\Windows\SystemWow64 on 64-bit systems.

Systemx64

Maps from C:\Windows\System32 on 64-bit systems.

AppData, LocalAppData, and CommonAppData

AppData maps from C:\Users\[username]\AppData\Roaming

LocalAppData maps from C:\Users\[username]\AppData\Local

CommonAppData maps from C:\ProgramData

When constructing the package, one has to consider these common locations where settings and data are commonly placed. If the package is constructed without one of these VFS folders referenced, then (similar to the Documents folder example), all Reads and Writes will work just as the original Win32 app.

Typically, we want to pre-configure repackaged applications with settings, or include required data files, as part of the package. When we use these three VFS folders, the runtime support generally has special limitations, possibly depending on the folder and on the OS runtime version:

• AppData - Prior to the 1903 Runtime, files in the VFS\AppDatafolder of the package are not visible to the application by VFSredirection. In these versions, attempts to write to this location would be treated the same as for a non-containerized application.

When the VFS\AppData folder is present, any attempt to write to a file under the user’s Appdata\Roaming folder, whether to overwrite an existing file or create a new one will fail.

Starting with the 1903 Runtime, VFS\AppData files and folders now redirect for Read and Write purposes. This Write redirection is performed by the OS using the same location as the one used by the Package Support Framework.

If your package might be used on down-rev systems, it may be safer to use the PackageSupportFramework in the package to ensure correct operation on any OS version.

• LocalAppData - On all versions (currently), files in theVFS\LocalAppData folder of the package are not visible to the application by VFS redirection alone.

The Package Support Framework may be added to make this area Read and Write capable.

• CommonAppData - On all versions (currently), files in theVFS\CommonlAppData folder of the package are not visible to the application by VFS redirection alone.

The Package Support Framework may be added to make this area Read and Write capable.

AppVPackageRoot

Maps from C:\

This acts as a catch-all for mappings that do not have another VFS mapping. Note that technically, the mapping is to the root folder of the drive letter that Windows is installed on, which is normally the C: drive.