Adding WindowsML CMake samples

[Mark Schofield (mschofie)]

Description

This PR adds some CMake samples for WindowsML. There's a few moving parts, so there's things to be discussed. Having a PR for folks to try out and get a "stake in the ground" should make things easier.

The samples need to add NuGet support to CMake, so I'm proposing that infrastructure, too. At the minute, that content is hosted in a personal repo - https://github.com/mschofie/NuGetCMakePackage - that would need to be moved somewhere more appropriate before this PR could be completed. That repo teaches CMake how to restore NuGet packages, and look for CMake scripts within those packages, allowing a NuGet package to have functional parity with MSBuild builds. Since the NuGet packages that I need to consume don't have CMake scripts within, the 'NuGetCMakePackage' infrastructure allows for 'overlay' files that are present as a stop-gap until I can migrate the content appropriately. I've created a PR for the NuGet infrastructure here if folks want to ask questions, or comment on the implementation.

Beyond the NuGet changes, the samples build two C++ console applications with CMake, using 'Visual Studio 17 2022' and 'Ninja Multi-Config' generators. The NuGet support is added through:

include(FetchContent)

FetchContent_Declare(
  NuGetCMakePackage
  GIT_REPOSITORY https://github.com/mschofie/NuGetCMakePackage
  GIT_TAG b13e013481605d134f498fd9fc3a123c416da197
)

FetchContent_MakeAvailable(NuGetCMakePackage)

Then NuGet dependencies are created with - for example:

add_nuget_packages(
    PACKAGES
        Microsoft.Windows.ImplementationLibrary 1.0.250325.1
        Microsoft.Windows.CppWinRT 2.0.250303.1
        Microsoft.WindowsAppSDK.Runtime 1.8.250907001
        Microsoft.WindowsAppSDK.ML 1.8.2084
)

Having called add_nuget_packages, the NuGet packages are findable through find_package:

find_package(Microsoft.Windows.ImplementationLibrary CONFIG REQUIRED)
find_package(Microsoft.WindowsAppSDK.ML CONFIG REQUIRED)

After which a CMake target is introduced with the same name that can be consumed by the CMake build, for example:

target_link_libraries(ResNetConsoleDesktop
    PRIVATE
        ResNetCommon
        Microsoft.WindowsAppSDK.ML_Framework # Use 'framework' mode.
        Microsoft.Windows.ImplementationLibrary
)

Feedback on any aspect - sample, naming conventions, approach, etc.. - is really appreciated.

Checklist

Note that /azp run currently isn't working for this repo.

• Samples build and run using the Visual Studio versions listed in the Windows development docs.
• Samples build and run on all supported platforms (x64, x86, ARM64) and configurations (Debug, Release).
• Samples set the minimum supported OS version to Windows 10 version 1809.
• Samples build clean with no warnings or errors.
• [For new samples]: Samples have completed the sample guidelines checklist and follow standardization/naming guidelines.
• Microsoft employees only: you can validate your changes by following the instructions here: https://www.osgwiki.com/wiki/WindowsAppSDK-Samples

[Jon Wiswall (jonwis)]

I'm doing something wrong because this has no effect on a local clone & build. I'm seeing all the build/* content as well as the __* dirs still listed.

[Mark Schofield (mschofie)]

Sorry, I'm not sure what could be going on... it's all good on my end. The file was missing it's final new-line... Perhaps that was it? Added it just in case.

The base branch was changed.

[Mark Schofield (mschofie)]

I've completed the PR in https://github.com/mschofie/NuGetCMakePackage, and updated this PR with the commit hash from that repo's main.

[Jon Wiswall (jonwis)]

Thanks Mark Schofield (@mschofie) ! This is great!

[Scott Jones (Scottj1s)]

Sorry for the belated feedback - my only concern is with the hardcoded activatableClass manifests in the NuGetCMakePackage project. I left a comment there suggesting build logic (e.g., an xslt) to transform each WinAppSDK nuget package's runtimes-framework\package.appxfragment into fusion schema, and then mt.exe merge up for the referencing app.

[Mark Schofield (mschofie)]

Sorry for the belated feedback - my only concern is with the hardcoded activatableClass manifests in the NuGetCMakePackage project. I left a comment there suggesting build logic (e.g., an xslt) to transform each WinAppSDK nuget package's runtimes-framework\package.appxfragment into fusion schema, and then mt.exe merge up for the referencing app.

Thanks! Yes, I 100% agree, the hardcoded 'activatableClass' entries are definitely a problem. I've been tracking Issues over in this repo, but don't have anything tracking that. Oh, hey! You filed an issue - thanks! I'll go and comment there. TBH, though, the main 'next step' is in this discussion, where I think there's an opportunity to move responsibilities around a little, and win32-manifest generation is definitely something I've been thinking about. As I mention there, having all the pieces "written down" is - I think - a useful milestone, but getting responsibilities in the right place with the right tooling, is going to take a little work.