Investigate AddPackageAsync hangs

[manodasanW]

Determine whether issue still repros with recent version and investigate:

dotnet/wpf#4097

[ekalchev]

This is easily reproducible. Just create an empty WPF app with .net 8.0 and call

await packageManager.AddPackageAsync(...)

it is not reproduced every time but usually on every 5 calls, hangs at least 1 time. It is only reproducible in Release

Calling the method synchrously packageManager.AddPackageAsync(...).GetWaiter().GetResult()
is a workaround for this issue but we noticed the installation of the same package is noticeable slower using the synchronous call.

This is not reproduced in WinUI3 app (or it is possible to be much harder to be reproduced)

[ekalchev]

We found that calling Task.Run(() => packageManager.AddPackageAsync(...).GetWaiter().GetResult())
from net48 application also causes AddPackageAsync task never to resolve.

The deadlocks are reproduced ONLY with Release builds

[dongle-the-gadget]

net48 has a different WinRT runtime, not CsWinRT.

[ekalchev]

net48 has a different WinRT runtime, not CsWinRT.

We are able to reproduce the deadlock with both .net8.0 and net48. I know that net core uses CsWinRT package and net48 uses Microsoft.Windows.SDK.Contracts but I am not sure where to submit a bug for Microsoft.Windows.SDK.Contracts

[ekalchev]

We found that if we turn off optimization for (net48) in Release it works.

<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|AnyCPU'">
      <Optimize>False</Optimize>
</PropertyGroup>

[manodasanW]

@ekalchev Are you using CsWinRT projections that you generate in net48 or are you using the built-in support?

[ekalchev]

We are using this nuget version https://www.nuget.org/packages/Microsoft.Windows.SDK.Contracts. We tried older version and it is still reproducible.

As much as I know CsWinRT nuget package can be used only with .net core 5 or later. So for net48 we use the nuget package above. Keep in mind the issue is present in both .net48 apps and .net core apps

We also reproduce with with .net8 app and using <TargetFramework>net8-windows10.0.17763</TargetFramework>

If you can't reproduce it, we can provide a code that reproduce it.

[krasidachev]

Would be great to have some progress here - same issue with my project!

[ekalchev]

We have identified additional details regarding this issue. By passing a CancellationToken to the affected methods, the freezing problem is resolved. Here is an example of how to implement this:

using(CancellationTokenSource cts = new CancellationTokenSource ())
{
await packageManager.StagePackageAsync(uri, null).AsTask(cts .Token)
}

Using this approach, we conducted thousands of package installations with AddPackageAsync and StagePackageAsync, and none of these operations froze, unlike when they were executed without a CancellationToken. We hope this information helps in addressing the issue or provides a viable workaround.

[Aetopia]

We have identified additional details regarding this issue. By passing a CancellationToken to the affected methods, the freezing problem is resolved. Here is an example of how to implement this:

using(CancellationTokenSource cts = new CancellationTokenSource ())
{
await packageManager.StagePackageAsync(uri, null).AsTask(cts .Token)
}

Using this approach, we conducted thousands of package installations with AddPackageAsync and StagePackageAsync, and none of these operations froze, unlike when they were executed without a CancellationToken. We hope this information helps in addressing the issue or provides a viable workaround.

Does the workaround still work if CancellationToken.None is passed around?

[ekalchev]

Yes

[Nevca]

I have also stumbled upon the same issue and it is very annoying. I would love to see this being worked on.

[ekalchev]

We have identified additional details regarding this issue. By passing a CancellationToken to the affected methods, the freezing problem is resolved. Here is an example of how to implement this:
using(CancellationTokenSource cts = new CancellationTokenSource ())
{
await packageManager.StagePackageAsync(uri, null).AsTask(cts .Token)
}
Using this approach, we conducted thousands of package installations with AddPackageAsync and StagePackageAsync, and none of these operations froze, unlike when they were executed without a CancellationToken. We hope this information helps in addressing the issue or provides a viable workaround.

Does the workaround still work if CancellationToken.None is passed around?

Actually, we found another PackageManager method AddPackageByAppInstallerFileAsync. We tried with to call AsTask with new CancelationToken and CancellationToken.None but it the problem was still present.

The workaround with the cancellationToken works only if it is constructed by CancellationTokenSource like that.

using(CancellationTokenSource cts = new CancellationTokenSource ())
{
await packageManager.AddPackageByAppInstallerFileAsync(uri, null).AsTask(cts .Token)
}