DynamicDependencies: Use Win11 APIs if available
Leverage the Win11 Dynamic Dependency API if available, otherwise use WinAppSDK's implementation (aka polyfill). The WinAppSDK DynDep C API handles this, thus benefiting all callers of WinAppSDK's C and WinRT DynDep API (e.g. C# via projections).
This happens on Win11 >= 22H2 (aka SV2).
NOTE: This makes the DDLM irrelevant on Win11 22H2+ (>SV2). A future (separate) PR will change the intaller to not install the DDLM packages on these systems.
*NOTE:* Persisted definitions aren't imported into the OS after OSupgrade to Win11 22H2+. If you create a persisted definition (LifetimeKind=FilePath|RegistryKey) on older you'll need to re-create them after the OS upgrades.
*NOTE:* MddGetResolvedPackageFullNameForPackageDependency()'s behavior differed from GetResolvedPackageFullNameForPackageDependency(). Both return null vs package full name when the PackageDependencyId is not resolved vs resolved but the HRESULT return value differed
|PackageDependencyId|WinAppSDK |OS API|
|-------------------|----------------------------------|------|
|unknown |HRESULT_FROM_WIN32(ERROR_NO_MATCH)|S_OK |
|not resolved |S_OK |S_OK |
|resolved |S_OK |S_OK |
MddGetResolvedPackageFullNameForPackageDependency() has been changed to match the OS API. A new OS API will be needed to distinguish between a known valid PackageDependencyId that's not been resolved yet vs an invalid/unknown PackageDependencyId.
NOTE: This change is compatible with the documented behavior. It'll be noted in the release notes.
NOTE: As a byproduct of return MddGetResolvedPackageFullNameForPackageDependency() error handling the WinRT APIs `PackageDependency.GetFromId()` and `PackageDependency.GetFromIdForSystem()` no longer fail for an unknown/invalid id e.g. `PackageDependency.GetFromId("not a valid id")`. Inappropriate later use will fail e.g.
```
var pd = PackageDependency.GetFromId("not a valid id");
var context = pd.Add();
// Add() fails and throws an exception
```
NOTE: A new OS API is needed to determine if a `PackageDependencyId` is a valid (known) value. WinAppSDK will be updated to use that when available.
https://task.ms/47326537
NOTE: Did the work to support Win11 21H2 but the OS may not fully support it. Left IsSupported() unchanged (Win11 >=22H2) for now while I investigate further
P.S. Increase test timeout to 120m
.NET8 introduced a [conditional breaking change](https://github.com/dotnet/docs/issues/35398) that influences how the runtime host looks for RID-specific assets. In NET8, support for non-portable RIDs (runtime identifiers specific to versions and distributions, such as win10-x86) is discontinued. The folder structure of the Microsoft.WindowsAppSDK NuGet is structured with assets marked using these non-portable RIDs:
The changes made to the `CopyFilesToStagingDir.ps1` script along with the project template changes should help support the .NET8 scenario. The selection of the project template's RIDs is conditional and based on the TFM chosen by the user. If NET8 is chosen, the RIDs become portable, enabling the runtime host to locate the RID-specific assets that were previously unattainable.
Microsoft.WindowsAppSDK.AppLicensingInternal.TransportPackage
From Version 1.5.0-main.20230925.1 -> To Version 1.5.0-main.20231018.0
Co-authored-by: dotnet-maestro[bot] <dotnet-maestro[bot]@users.noreply.github.com>
* removing BuildTools/WASDK Nuget Package from ContentNugetPackages
* removing dev16 projects
* initial commmit
* namespace change + moving installer to AsyncFunc + comment debounce + formal params
* blank spaces
* dll name change
* handling case if the packageID can't get picked up from Wizard Data
* Adding installation error logic + refactoring
* removing return from failed packageID retrieval; should try and install anyway (and fail)
* never mind
* error message semantics'
* whitespaces
* target .net6 comment
* spacing, cont'd
* spacing cont'd cont'd
* single project csproj restore, unsure of why those changes were there
* TemplateUtilities
* wapproj changes 1
* wap/csproj separate wizardextensions?
* one project at a time
* BOM
* removing all packagerefs from wapproj template, it's not needed
* bom fix
* eof
---------
Co-authored-by: Shashank Nayak <shasnayak@microsoft.com>
Co-authored-by: Bob Pulliam <bpulliam@microsoft.com>
WindowsAppRuntimeInstall.exe doesn't have a version resource. That means all crash telemetry comes in for version 0.0.0.0, which prevents seeing if fixes in the latest version have improved reliability.
This fix adds a version resource using the existing AssemblyInfo.ver. This won't provide enough information to see if/which servicing release the installer is from, but it at least will show which major.minor version it is from.
Also
* Manually update DevChcek (awaiting Maestro to automate that thing it's supposed to be doing. Oh, Will...)
* Update TAEF from 10.75.221207001 to 10.82.230714001. Update C++/WinRT from 2.0.221121.5 to 2.0.230706.1
* Something weird's failing in the ARM64 tests. Disabling ARM64 temporarily
* Use CoreCompileDependsOn to ensure that version info is added before XamlPreCompile, not just CoreCompile
* restructured to enable apps to easily include WindowsAppSDK-VersionInfo.cs exactly once for all compilations (Xaml, etc)
* removed cruft target
TDBuild
Keith Mahoney
Shashank
Howard Kapustein
Kyaw Thant
Shashank Nayak
reunion-maestro-bot
alexlamtest
Duncan MacMichael
Kyaw Thant
reunion-maestro[bot]
Mike Crider
Bob Pulliam
Scott Jones
