Allow third parties to ship framework packages

[JaiganeshKumaran]

At the moment only Microsoft can ship MSIX framework packages (no instructions provided on how a third party can do it; before MSIX anyone could do it with a redistributable). Because of this, most libraries are packaged with applications themselves, which completely defeats the point of having dynamically-linked libraries in the first place instead of statically-linked ones¹.

Footnotes

1. Statically linking native libraries is not always possible because you may be using a managed language. ↩

[DarranRowe]

Just for clarification, since "ship" is ambiguous here. Is this question about getting third party libraries into the Windows Store?
If it is about the generation of framework packages then Framework is documented. Ship is ambiguous because you can also technically generate the .MSIX framework package and make it available for download and sideloading.

[JaiganeshKumaran]

I do obviously want it on the Store so that installing a Store app that needs my framework will also install that automatically.

Plus that is not documentation - that is just schema reference. Like I would not know where to start - which template in VS to click and modify.

[DarranRowe]

Well, while I can't say anything about getting a framework package into the Windows Store, or whether that is even allowed, I am able to provide information on how to make the package itself.
There are two main things to point out here. First, the process for generating a package for sideloading is going to be the same as the process for generating a package for the store. Secondly, the only way that I know of to create a framework package is to use makeappx.exe directly. I have not looked too hard into third party project templates or even the Visual Studio's Application Packaging Project template though. If you can find a way of generating the framework package inside Visual Studio, then post that information here, it would be very useful to know.
Using makeappx to generate the package would generally follow the concepts in "Package from the command line". There are a couple of modifications to the base AppxManifest.xml files though. As documented in the Framework element documentation, a package marked as a framework package cannot declare dependencies on other packages, and a framework package cannot define Applications or Capabilities. This means that the base blank AppxManifest file is closer to:

<?xml version="1.0" encoding="utf-8"?>
<Package
  xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10"
  xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10">
  <Identity Name="" Version="" Publisher="" ProcessorArchitecture="" />
  <Properties>
    <DisplayName></DisplayName>
    <PublisherDisplayName></PublisherDisplayName>
    <Description></Description>
    <Logo></Logo>
    <Framework></Framework>
  </Properties>
  <Resources>
    <Resource Language="" />
  </Resources>
  <Dependencies>
    <TargetDeviceFamily Name="Windows.Desktop" MinVersion="" MaxVersionTested="" />
  </Dependencies>
</Package>

The TargetDeviceFamily is still needed, but you cannot declare a dependency on things like VCLibs or the Windows App SDK. These are dependencies that the main application package itself must declare.
There is also something else sneaky here, as documented in the Logo element documentation, the logo image can be given as either a direct path to an image file or as a resource. Because of how framework packages are, you rarely see the image itself. This means that you can get away without providing any scaled versions of the logo. If you don't localise the strings in the package either and you don't use these resources in some other way, you can get away without the resources.pri file.
As an interesting side note to the above point. If you look at the VCLibs Appx packages, you will notice that these lack a resources.pri file. You can find these on your system after installing Visual Studio. They can be found in %ProgramFiles(x86)%\Microsoft SDKs\Windows Kits\10\ExtensionSDKs.

As a bit more of a concrete example. For some of my desktop application sample and test projects, I use a little self written library called WindowBase.dll. Suppose I wanted to package that up into a framework package. First, I would start off with the AppxManifest.xml file.

<?xml version="1.0" encoding="utf-8"?>
<Package xmlns="http://schemas.microsoft.com/appx/manifest/foundation/windows10">
  <Identity Name="My.WindowBase" Publisher="CN=Me" ProcessorArchitecture="x64" />
  <Properties>
    <Framework>true</Framework>
    <DisplayName>WindowBase Framework</DisplayName>
    <PublisherDisplayName>Darran</PublisherDisplayName>
    <Logo>Logo.png</Logo>
  </Properties>
  <Dependencies>
    <TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.17763.0" MaxVersionTested="10.0.22621.0" />
    <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.17763.0" MaxVersionTested="10.0.22621.0" />
  </Dependencies>
</Package>

The Publisher attribute in Identity should match the information in the store, or the certificate that you will be using to sign it for sideloading. Everything else should be filled out accordingly.
The logo is a direct reference to the logo file path in the package and since the library itself isn't using any MRT/MRT core resources and I am not using any localised strings, I can completely forgo the generation of resources.pri here.
After this, I copy the files that I want into a directory for the package.

I then use the makeappx.exe command line to build the package.

makeappx pack /h SHA256 /d package /p ....\Packages\WindowBase_1.0.0.0-x64.msix

That is from the directory that contains the package directory, which is the package layout directory. The command above does contain a relative path to a Packages directory. This directory does exist, and the /p option specifies the package file name. It is also possible to create the package using a mapping file. This allows you to specify the package layout without having to make a layout directory.
To reference this framework package from the main application package, you just add it as a PackageDependency.

  <Dependencies>
    <TargetDeviceFamily Name="Windows.Universal" MinVersion="10.0.17763.0" MaxVersionTested="10.0.22621.0" />
    <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.17763.0" MaxVersionTested="10.0.22621.0" />
    <PackageDependency Name="Microsoft.VCLibs.140.00.UWPDesktop" MinVersion="14.0.30704.0" Publisher="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" />
    <PackageDependency Name="My.WindowBase" MinVersion="1.0.0.0" Publisher="CN=Me" />
  </Dependencies>

You should also add any package dependencies that the framework package depends on here too.

As stated, this is the only way I know of how to do this. I also use makeappx to make packages for desktop applications most of the time since the Visual Studio application packaging project really messes up the layout for C++ applications. The application packaging project doesn't do well with more complex layouts here.

[softworkz]

the only way that I know of to create a framework package is to use makeappx.exe directly. I have not looked too hard into third party project templates or even the Visual Studio's Application Packaging Project template though. If you can find a way of generating the framework package inside Visual Studio, then post that information here, it would be very useful to know.`

@DarranRowe - I was able to get this working with a .wapproj to build framework packages for the WebView2 fixed runtime.

The key was to overwrite two targets (which expect an application node in the manifest). My project file ends like this:

  <Import Project="$(WapProjPath)\Microsoft.DesktopBridge.targets" />
  <ItemGroup>
    <PackageReference Include="Microsoft.Windows.SDK.BuildTools" Version="10.0.22621.756" PrivateAssets="all" />
  </ItemGroup>
  <Target Name="_ConvertItems">
  </Target>
  <Target Name="_GenerateDesktopBridgeAppxManifest">
  </Target>
</Project>