Add scaffolding for C# projection of the SDK

[florelis]

Summary of the Pull Request

This adds the scaffolding for building a C# projection of the WSLC SDK. The projection is created by first making a C++/WinRT wrapper over the base API, and then using CsWinRT to project that to C#. This PR includes only the changes to the build process, and a projection of a few types as a proof of concept.

PR Checklist

• Closes: Link to issue #xxx
• Communication: I've discussed this with core contributors already. If work hasn't been agreed, this work might be rejected
• Tests: Added/updated if needed and all pass
• Localization: All end user facing strings can be localized
• Dev docs: Added/updated if needed
• Documentation updated: If checked, please file a pull request on our docs repo and link it here: #xxx

Detailed Description of the Pull Request / Additional comments

This PR builds on top of #40182, so I'll mark it as a draft until that one is merged.

The implementation is made with C++/WinRT because C++ is better suited than C# for the kind of calls we need to make to use the SDK (like getting function outputs by passing in pointers), and WinRT allows projecting to C# without us having to directly deal with PInvoke interop.

The C++/WinRT is built on top of the SDK. This unfortunately means that a consumer will need to have 3 DLLs: the SDK, the C++/WinRT layer, and the C# projection. As an improvement, we could build the C++/WinRT layer on top of the service API to avoid going through the SDK.

At the C# layer no code is needed for the API, as everything is generated by CsWinRT. The only code needed is for handling object activation. If the projection proves to be unsuitable (for example, if we don't like the types it uses), we can mark the CsWinRT projection as private (CsWinRTIncludesPrivate) and create a thin C# layer on top of it that won't have to deal with interop at all.

Validation Steps Performed

Manually tested building a local NuGet package and using it in a project like this:

Project .csproj:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
	  <RuntimeIdentifier>win-x64</RuntimeIdentifier>
    <TargetFramework>net10.0-windows10.0.22000.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
    <Nullable>enable</Nullable>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.WSL.Containers" Version="2.7.0-build688" />
  </ItemGroup>
</Project>

Program.cs:

using Microsoft.WSL.Containers;
var ss = new SessionSettings("session", @"C:\storage\path");
ss.MemoryMb = 1024;
ss.CpuCount = 5;
ss.FeatureFlags = SessionFeatureFlags.EnableGpu;
ss.VhdRequirements = new VhdRequirements("vhd", 1024, VhdType.Dynamic);
var s = Session.Create(ss);

[JohnMcPMS]

If we are going with C++/WinRT, I would prefer we do the winget model and compile it into the WSLC SDK dll. That would mean one less binary is required and remove the potential for consumers to mix and match. What that looks like in cmake 🤷

[florelis]

If we are going with C++/WinRT, I would prefer we do the winget model and compile it into the WSLC SDK dll. That would mean one less binary is required and remove the potential for consumers to mix and match. What that looks like in cmake 🤷

Sure. I just didn't want to take the time to understand if there would be any conflict from exposing both from the same DLL or how to set it up. If we do go with this implementation, I can add it later, as we probably care more about covering the API surface than the DLL detail.

[florelis]

Note: I want to keep this PR scoped to the concept of using C++/WinRT to create the C# projection and the changes needed to the build process. For comments about the details of the C++/WinRT implementation (e.g., accepting 0 to reset to the default), I'll make note of them but I'll make the changes in a future PR focused on the implementation and including more of the API surface.

[JohnMcPMS]

Any values only settable in the constructor should be declared const to prevent (actually, reduce) changes to them that might invalidate their c_str location.

[benhillis]

The feature/wsl-for-apps branch is now defunct. If your PR is still valid, please retarget the master branch. Reach out to @benhillis for help if needed.