Consider harvesting the appx fragment files from each nuget package

[Scottj1s]

Consider transforming the activatableClass/proxyStub/etc elements from each nuget package's .\runtimes-framework\package.appxfragment file into a fusion manifest fragment that can then be mt.exe merged up into the app's manifest. This would simplify maintenance with a single source of truth, etc.

See the GenerateAppManifestFromAppx task in Microsoft.WindowsAppSDK.SelfContained.targets, or use an xslt something like this:

<?xml version="1.0"?>

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:ms="http://schemas.microsoft.com/appx/manifest/foundation/windows10">

<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>

<xsl:param name="ApplicationName" />

<xsl:template match="/">
  <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
    <xsl:for-each select="ms:Package/ms:Extensions/ms:Extension">
      <file>
        <xsl:attribute name="name">
          <xsl:value-of select="ms:InProcessServer/ms:Path" />
        </xsl:attribute>
        <xsl:for-each select="ms:InProcessServer/ms:ActivatableClass">
          <activatableClass xmlns="urn:schemas-microsoft-com:winrt.v1">
            <xsl:attribute name="name">
              <xsl:value-of select="@ActivatableClassId" />
            </xsl:attribute>
            <xsl:attribute name="threadingModel">
              <xsl:value-of select="@ThreadingModel" />
            </xsl:attribute>
          </activatableClass>
        </xsl:for-each>
      </file>
    </xsl:for-each>
  </assembly>
</xsl:template>

</xsl:stylesheet>

[mschofie]

Well, I think the right answer - that I allude to in this discussion - is to do what MSBuild does. If we can get an abstract description of the package, that associates .winmd files to implementation .dlls, then we can run the same logic that MSBuild runs to generate the win32-manifest based on the activatable classes in the .winmd file, and point the manifest to the implementation for those activatable classes. I think relying on the .winmd is a stronger convention than the package-manifest fragment.

IIRC, the MSBuild logic is only available as an MSBuild task - there isn't a standalone EXE that it wraps. Perhaps invoking the MSBuild task from pwsh would be an OK stop-gap...

---

Ah. Sorry, I'm wrong. I thought msbuild generated both manifests (AppX- and Win32-) from the .winmd file. But you're right - the WindowsAppSdk derives the Win32-manifest from the AppX-manifest. I'm a little torn - generating the Win32-manifest from the AppX-manifest would account for "post generation edits" to the AppX-manifest...? But it means a dependency on the AppX-manifest-fragment convention and moves Win32-manifest generation one more level away from the .winmd file.