The problem with Framework packages in MSIX and a proposed solution
Microsoft created the concept of “Framework” packages, which are designed to contain common dlls that might be needed for multiple packages, which could then declare these framework packages as dependencies which get layered in automatically at runtime. A good idea that allows the framework package to be updated with security fixes independently.
The implementation, however, is problematic. As an example, I point to Windows.Runtime_1.4.
The Windows.Runtime_1.4 dependency is automatically added by the Microsoft Packaging Tool for most applications to solve certain types of shortcut issues. But there are two “architecture” (aka “bitness”) versions of this dependency, one containing x86 dlls and one containing x64 dlls.
For the purpose of why the dependency is added automatically by the Microsoft MSIX Packaging tool, the client (the device the package is installed into) OS architecture dictates the architecture of the dependency package, i.e. since we are using 64-bit OSs 99.999% of the time today we need the x64 version of the dependency.
In the AppXManifest schema today, we can only specify the package name, and there is no option to specify the architecture. So as long as we package on an x64 OS and deploy to x64 OS we are OK if that is the only need for the dependency.
Unfortunately, the base application might be 32-bit and also require the WIndows.Runtime dependency, which would need to be the x86 version of the dependency. But alas, there is no way to specify the architecture in the dependency and such packages are not a candidate for MSIX.
This is just one concrete example of the dependency problem; VCLIBS is another.
As I look at the situation there are two very acceptable alternative solutions that Microsoft could embrace to solve this.
Extend the AppXManifest schemas to add an “Architecture” parameter to the Dependency element. This, by itself, would allow a single architecture solution. But it would not solve the need for situations requiring both bitnesses without #2 also.
Change the way that these Framework packages are constructed. Currently they place the dlls at the root folder of the dependency package. While this folder is in the load library search algorithm for dll loading, it is not the only option. Instead, place these dll files in a VFSSYSTEMx64 or VFSSYSTEMx86 folder of the dependency package as appropriate. This is still in the automatic search pattern for MSIX/AppX and will be found.
For solution #2 in a vacuum, that would mean consolidating the x64 and x64 Windows.Runtime packages into a single package would be necessary. With #1 implemented, we could live with separate architecture dependency packages, although they would still need to have the dlls under the VFS folders to allow both framework packages to be added when necessary.
To be clear, it is the VCLibs case that is more critical to this post, but the Windows.Runtime is also an issue (just easier to explain).
Microsoft created the concept of “Framework” packages, which are designed to contain common dlls that might be needed for multiple packages, which could then declare these framework packages as dependencies which get layered in automatically at runtime. A good idea that allows the framework package to be updated with security fixes independently.
The implementation, however, is problematic. As an example, I point to Windows.Runtime_1.4.
The Windows.Runtime_1.4 dependency is automatically added by the Microsoft Packaging Tool for most applications to solve certain types of shortcut issues. But there are two “architecture” (aka “bitness”) versions of this dependency, one containing x86 dlls and one containing x64 dlls.
For the purpose of why the dependency is added automatically by the Microsoft MSIX Packaging tool, the client (the device the package is installed into) OS architecture dictates the architecture of the dependency package, i.e. since we are using 64-bit OSs 99.999% of the time today we need the x64 version of the dependency.
In the AppXManifest schema today, we can only specify the package name, and there is no option to specify the architecture. So as long as we package on an x64 OS and deploy to x64 OS we are OK if that is the only need for the dependency.
Unfortunately, the base application might be 32-bit and also require the WIndows.Runtime dependency, which would need to be the x86 version of the dependency. But alas, there is no way to specify the architecture in the dependency and such packages are not a candidate for MSIX.
This is just one concrete example of the dependency problem; VCLIBS is another.
As I look at the situation there are two very acceptable alternative solutions that Microsoft could embrace to solve this.
Extend the AppXManifest schemas to add an “Architecture” parameter to the Dependency element. This, by itself, would allow a single architecture solution. But it would not solve the need for situations requiring both bitnesses without #2 also.
Change the way that these Framework packages are constructed. Currently they place the dlls at the root folder of the dependency package. While this folder is in the load library search algorithm for dll loading, it is not the only option. Instead, place these dll files in a VFSSYSTEMx64 or VFSSYSTEMx86 folder of the dependency package as appropriate. This is still in the automatic search pattern for MSIX/AppX and will be found.
For solution #2 in a vacuum, that would mean consolidating the x64 and x64 Windows.Runtime packages into a single package would be necessary. With #1 implemented, we could live with separate architecture dependency packages, although they would still need to have the dlls under the VFS folders to allow both framework packages to be added when necessary.
To be clear, it is the VCLibs case that is more critical to this post, but the Windows.Runtime is also an issue (just easier to explain). Read More
