Fix implementation of IFindReferenceTargetsCallback::FoundTrackerTarget - #115921
Conversation
|
Tagging subscribers to this area: @dotnet/interop-contrib |
…get to correctly record the found reference paths.
00f8f7c to
d4fb6e5
Compare
|
Maui is crashing because of this, we will need this on Preview 5 |
|
/backport to release/10.0-preview5 |
|
Started backporting to release/10.0-preview5: https://github.com/dotnet/runtime/actions/runs/15279956054 |
|
/backport to release/10.0-preview5 |
|
Started backporting to release/10.0-preview5: https://github.com/dotnet/runtime/actions/runs/15283671298 |
|
Can I request a backport to net9.0 as well? This is blocking us implementing a proper out-of-process WinRT server using CsWinRT. |
|
This didn't end up fixing the CsWinRT issue that you found. This was only a bug in the new ComWrappers implementation. There's still a latent bug somewhere in Windows that you found. |
Fixes #115881
The implementation of
FoundTrackerTargetfrom the ComWrappers refactoring incorrectly used the target as the source and compared syncblocks before creating the connection from source to target. As a result, the target object's live was not tied to the source object's lifetime and was released early even though it was still referenced.