Recommended way of merging manifests for self-contained apps

[Steelskin]

The documentation for making a self-contained app gives instructions on how to achieve this for a Visual Studio-based build, mainly, setting the following in the project configuration:

<WindowsAppSDKSelfContained>true</WindowsAppSDKSelfContained>

However, it is unclear what should be done with other build systems. Looking at the built artifacts and the nuget package content, it seems that merging the Windows App SDK manifest with the app manifest is required. However, the nuget package contains 2 sets of manifests:

1. manifest files in manifests/**/*.manifest
2. the embedded manifest in the MSIX at tools/MSIX/wint10-${ARCH}/Microsoft.WindowsAppRuntime.${MAJOR}.${MINOR}.msix

The files in manifests/**/*.manifest have an issue if fed directly to the mt.exe invocation. One of them contains an empty file node. While this merges just fine, the resulting binary is unusable.

  <file name="" />

However, the Visual Studio build goes a different route, based on the contents of the file at build/Microsoft.WindowsAppSDK.SelfContained.targets in the nuget package (taken from the Code node in this file):

            var headerF = @"<?xml version='1.0' encoding='utf-8' standalone='yes'?>
<assembly manifestVersion='1.0'
    xmlns:asmv3='urn:schemas-microsoft-com:asm.v3'
    xmlns:winrtv1='urn:schemas-microsoft-com:winrt.v1'
    xmlns='urn:schemas-microsoft-com:asm.v1'>";
            var sb = new StringBuilder();
            sb.AppendLine(headerF);
            
            var dllFileFormat = RedirectDlls ? 
                @"    <asmv3:file name='{0}' loadFrom='%MICROSOFT_WINDOWSAPPRUNTIME_BASE_DIRECTORY%{0}'>" :
                @"    <asmv3:file name='{0}'>";

            if (!string.IsNullOrEmpty(InAppxManifest))
            {
                XmlDocument doc = new XmlDocument();
                doc.Load(InAppxManifest);
                var nsmgr = new XmlNamespaceManager(doc.NameTable);
                nsmgr.AddNamespace("m", "http://schemas.microsoft.com/appx/manifest/foundation/windows10");
                var xQuery = "./m:Package/m:Extensions/m:Extension/m:InProcessServer";
                var dllFiles = (from di in (new DirectoryInfo(MsixContentDir).EnumerateFiles("*.dll")) select di.Name).ToList();
                foreach (XmlNode winRTFactory in doc.SelectNodes(xQuery, nsmgr))
                {
                    var dllFileNode = winRTFactory.SelectSingleNode("./m:Path", nsmgr);
                    var dllFile = dllFileNode.InnerText;
                    var typesNames = winRTFactory.SelectNodes("./m:ActivatableClass", nsmgr).OfType<XmlNode>();
                    sb.AppendFormat(dllFileFormat, dllFile);
                    sb.AppendLine();
                    foreach (var typeNode in typesNames)
                    {
                        var attribs = typeNode.Attributes.OfType<XmlAttribute>().ToArray();
                        var typeName = attribs
                            .OfType<XmlAttribute>()
                            .SingleOrDefault(x => x.Name == "ActivatableClassId")
                            .InnerText;
                        var xmlEntryFormat =
@"        <winrtv1:activatableClass name='{0}' threadingModel='both'/>";
                        sb.AppendFormat(xmlEntryFormat, typeName);
                        sb.AppendLine();
                        dllFiles.Remove(dllFile);
                    }
                    sb.AppendLine(@"    </asmv3:file>");
                }
                if(RedirectDlls)
                {
                    foreach (var dllFile in dllFiles)
                    {
                        sb.AppendFormat(dllFileFormat, dllFile);
                        sb.AppendLine(@"</asmv3:file>");
                    }
                }
            }
            sb.AppendLine(@"</assembly>");
            var manifestContent = sb.ToString();
            File.WriteAllText(OutAppManifest, manifestContent, Encoding.UTF8);

This seemingly reads the AppxManifest.xml file embedded in the MSIX package and re-builds the resulting manifest for consumption by the mt.exe invocation.

Questions:

1. What is the purpose of the manifests files at manifests/**/*.manifest?
2. Why is one of them unsuitable for consumption by mt.exe?
3. Is it okay to use them for merging after cleaning the faulty line?
4. What is the recommended way of merging the manifests if you are not using a Visual Studio build?

[DarranRowe]

Since I'm not in a position to answer 1 and 2, I won't even attempt to.

3. They are inaccurate. They don't contain the registrations for widgets and 1.6-experimental2 still contains the webview2 registrations even though it was changed to be an external component. The Reg Free WinRT registrations will get you most of the way there, but you will be missing some things. Annoyingly, reading the AppxManifest.xml file and using that is the best way to get the complete set of registrations.
4. I would say mt.exe is still the way to go. It is part of the Windows SDK, not Visual Studio. You can install the Windows SDK independently of Visual Studio. What's more, if you don't want to install the Windows SDK, then you can grab the Windows SDK Build Tools NuGet package and you could even get the Windows SDK C++ NuGet package if you want the extra Microsoft headers and libraries on top of the build tools.

--Edit--
There is one thing that I forgot to mention. If you are planning to try use a separate set of tools to build a Xaml based application then be aware that Microsoft only supports this in an MSBuild based environment.
If you look through the NuGet package, you will find the steps to build Xaml based applications in the MSBuild .props and .targets files. This includes all of the generated files and tools that it uses. While it is possible to build a Xaml based application this way, it is completely unsupported.

[Steelskin]

We ended up reading the AppxManifest.xml and re-building the XML ourselves. This is a case where we cannot use MSBuild so we do have to use our own tools. Thanks for the answer!

[DarranRowe]

Reading the AppxManifest.xml file seems like it is the easiest course of action.
With the wording of your reply, I want to clarify something. All of the Windows SDK tools can be used independently of MSBuild too. All of the tools should be documented and fully usable on the command line.
The only reason why I mentioned using the NuGet package if you didn't want to install the Windows SDK itself, is that it is easy to manually download the .nupkg file itself and the file is just a renamed .zip file. So the idea is to extract the .nupkg file, put the directory that contains all of the .exe files into the path and everything should be usable. It does contain a subset of the tools, but the missing tools are less likely to be useful.