Provide a release package for non-nuget compatible builds

[MarkIngramUK]

Proposal: Provide a release package for non-nuget compatible builds

Summary

Our applications are cross-platform C++, and as such we use CMake for our projects. CMake doesn't support nuget, so in order to use WindowsAppSDK, we need to manually download the Microsoft.WindowsAppSDK.x.x.x-yyy.nupkg and extract the contents. There's no documentation as to what files are required for native C++ builds, so I've been digging around the package looking for relevant headers, libs, dlls, and winmd (as we have a CMake build step that uses cppwinrt to generate headers). This was OK with 1.0 experimental1, but with 1.0 preview1 there are additional directory structures which aren't obvious whether they're required or not. e.g. /include/FrameworkUdk, or in the case of lib/native/windows/<arch>/release and lib/native/include doesn't seem to fit with the existing structure.

I propose a C++ compatible zip release with the following directory structure:	Directory	Purpose
/bin/[arch]	DLLs
/include	Header files
/lib/[arch]	DLL import libraries, or static libraries
/winmd	Windows metadata and XML files (if required?)

Where [arch] is arm64, x64, or x86.

Rationale

• To make it easier / supported / official for C++ cross platform developers to use WindowsAppSDK

Scope

Capability	Priority
This proposal will allow developers to download a zip file of the release with a predictable directory structure	Must
This proposal will allow developers to continue using Nuget package releases	Must

Important Notes

-

Open Questions

-

[DrusTheAxe]

Are you advocating CMake specifically, a .zip containing some semi-structured organization and/or other format(s)?

[MarkIngramUK]

Just a zip file. I can then write an extraction function in our CMake scripts.

[BenJKuhn]

Some of the diversity in the directory structure was churn / work in progress that should be cleaned up in a future update.

@MarkIngramUK Assuming consistent structure in the nuget, which is essentially just a ZIP and accessible via command line using nuget.exe or nuget APIs (https://docs.microsoft.com/en-us/nuget/api/package-base-address-resource), would that be sufficient?

[MarkIngramUK]

I think some of the issue is that when using Visual Studio, the process is simple; add a reference to the Nuget package and away you go. However when you don't have that luxury, you're just left with trying to work out how to use WindowsAppSDK on your own. I can open up the Nuget package, but I don't know what files are required to make the features I'm using work (e.g. MRTCore and AppLifecycle). I can add all of the contents, but then I get questions from colleagues like, "What is FrameworkUdk", and my answer is, "I don't know.".

Ultimately I see Nuget as an additional complication. As cross-platform C++ developers, we're used to configuring include directories, lib directories, and copying binaries to output directories. I feel like we need a release mechanism that works for us too.

This is why I was suggesting a smaller, simpler, package, just for C++ developers, who want to adopt WindowsAppSDK. Having directories like /bin/x64, /lib/x64, /include, and /winmd is fairly self-documenting, and I know I'm not going to accidentally submit anything to our source control repo that is only required for Visual Studio or MSBuild integration or similar.

[MarkIngramUK]

Or thinking about it, adding WindowsAppSDK to vcpkg would also be a great solution. We don't currently use vcpkg, but if it enabled us to more easily use WindowsAppSDK, then I'd certainly adopt it.

[BenJKuhn]

Vcpkg is a great suggestion, and one that's already on our radar per issue #74 that you opened in the past. We haven't lost track of that one, just haven't made it that far in the backlog. We're going to continue to focus on the VS msbuild & .NET experience a little longer before we start taking on new scenarios. In the meantime we will continue to make the nuget more consistent and easier to consume. Since #74 would satisfy this request as well, I'm going to resolve this as a duplicate. If there's additional input you have about how to provide support in cmake or vcpkg, let's move the discussion over to that issue to avoid duplication.

[MarkIngramUK]

I actually forgot I had raised #74 when I posted my last comment 🤦‍♂️ .

I still think there's merit in providing a zip for the non MSBuild scenario in the intermediate period, but I would settle for a more consistent structure in the nuget package, and perhaps just a little bit of info on what files certain features actually require. e.g. DWriteCore was added in the 1.0 preview1 release, but if we're not using DWriteCore immediately, can we just remove the binaries, libs, and headers, to avoid committing them to our source control repo? Or Microsoft.WindowsAppRuntime.Bootstrap.Net.dll, FrameworkUdk directory / Microsoft.Internal.FrameworkUdk.lib, etc.

Also, what about the manifests that are in the latest nuget package? Microsoft.WindowsAppSdk.Foundation.manifest looks like it contains activatableClass elements only. When is this manifest required? At what point do I need to embed these entries into our application manifest?

As long as some of the guess work is taken out, then it will make updating the WindowsAppSDK much simpler for us.

Thanks @BenJKuhn 👍

[MarkIngramUK]

I've just grabbed preview2, and started the process of extracting relevant files. The lib directory highlights the issue I'm describing:

I can guess that net5.0___ relates to .NET, so I can avoid that. I know the win10___ directories are native import libraries, but then we've got uap___. I know I need some winmd files from here, and I would normally guess at using just the uap10.0 directory. However, in preview1, we had a Microsoft.Foundation.winmd file, which now doesn't exist in uap10.0 - but it does exist in uap10.0.17763 and uap10.0.18362. I'm left wondering if I need the file at all, or if I should take it from one of those versioned directories? I now have to spend time experimenting, just to cleanly upgrade the SDK.

[MarkIngramUK]

Looks like git is doing the heavy lifting for me:

renamed: [snip]/Microsoft.Foundation.winmd -> [snip]/Microsoft.Windows.System.winmd

[MarkIngramUK]

Argh.

1>cppwinrt : error Type 'Microsoft.UI.Dispatching.DispatcherQueue' could not be found 1> method: DispatcherQueue 1> type: Microsoft.UI.Xaml.IDependencyObject 1> database: [snip]\Microsoft.UI.Xaml.winmd

Looks like I'm missing something, but I don't know what... I have all of the winmd files from microsoft.windowsappsdk.1.0.0-preview2.nuget\lib\uap10.0.

cppwinrt version: 2.0.210722.2 winsdk version: 10.0.20348.0

Input to cppwinrt (from preview2):

Microsoft.UI.Text.winmd
Microsoft.UI.Xaml.winmd
Microsoft.Web.WebView2.Core.winmd
Microsoft.Windows.ApplicationModel.DynamicDependency.winmd
Microsoft.Windows.ApplicationModel.Resources.winmd
Microsoft.Windows.ApplicationModel.WindowsAppRuntime.winmd
Microsoft.Windows.AppLifecycle.winmd
Microsoft.Windows.PushNotifications.winmd
Microsoft.Windows.System.Power.winmd
Microsoft.Windows.System.winmd

For now, I've deleted Microsoft.UI.Text.winmd and Microsoft.UI.Xaml.winmd and cppwinrt successfully generates the header files again.