WPF + .Net 5 + WinRT APIs not yet functional

Problem description:

Critical WinRT APIs when consumed from a WPF .Net 5 app are not yet functional. One example

                Progress<DeploymentProgress> progressCallback = new Progress<DeploymentProgress>((op) =>
                {
                    //var appxProgress = new AppxProgress(op.percentage, "...");
                    //progress.Report(appxProgress);
                });

                var pkgManager = new PackageManager();

                // MP! fixme: why do we hang on the await on occasion?
                Debug.WriteLine("Installing package ...");
                DeploymentResult result = await pkgManager.AddPackageAsync(uriToAppx, urisToDependencies, DeploymentOptions.ForceTargetApplicationShutdown).AsTask(progressCallback).WaitOrCancel(stop);
                Debug.WriteLine("Package installed ...");

After commenting out the UI update portion of the code, AddPackageAsync still hangs. If I remove the use of DeploymentProgress, AddPackageAsync always completes.

Actual behavior:

Call hangs.

Expected behavior:

Call should complete.

Minimal repro:

Shown above. You can remove the WaitOrCancel() bit for your testing. It’s there only to support cancellation, which happens to work even when the call is hung.

The repo that contains a “working” solution is located here: https://github.com/Noemata/AppxInstaller

The call hangs about 50% of the time. So it works 50% of the time when re-run the app. 😦

[ryalanms]

I tagged him so he could comment. This looks like a CsWinRT issue.

[Noemata]

@AaronRobinsonMSFT , if you looked at the provided repos (https://github.com/Noemata/AppxInstaller.Core versus https://github.com/Noemata/AppxInstaller), you would agree that in this specific case with the API mix that is at play, the two (.NET 3.1 and .NET 5) should have exactly the same behavior when creating a self contained executable. The fact that both .NET 5 and .NET Core 3.1 work exactly the same way when a self contained executable isn’t being created only emphasizes the point that there is an issue with .NET 5!

As for your “intentional breaking change”, that is grief Microsoft keeps hoisting on both itself and the users of its products… Adding “may not be a priority to bring back”, isn’t relevant here because this is an apples to apples comparison. You just need to take the time to look at the two sample projects. They are equivalent in every respect and introduce nothing that hasn’t been promised or promoted as working.