[BUG] PropertyChanged events weaved by ReactiveUI.Fody do not get fired under specific conditions

[ashelleyPurdue]

Describe the bug
Under a very specific set of circumstances, the PropertyChanged event of a ReactiveObject weaved by Fody will not be fired when you change a property's value.

These conditions are:

• You must be using .Net Core 3.0
• You must be in a WPF project. It does not appear in console applications or unit tests.
• You must subscribe to the PropertyChanged event with a lambda expression
• Said lambda expression must capture at least one value from the enclosing function.
• You cannot subscribe to a button click event in the same function that you subscribed to PropertyChanged.

If ANY of the above conditions are NOT met, the bug will NOT appear.

To demonstrate, I've prepared a super-small project, because code speaks louder than comments: https://github.com/ashelleyPurdue/here_is_a_very_specific_bug_that_i_would_like_to_showcase

The glitched behavior occurs in the project named "Core"(which, predictably, uses .Net Core), but not in the project named "Framework"(which--you guessed it-- uses .Net Framework).

Steps To Reproduce

• Clone the repo mentioned above
• Set "Core" as your startup project
• Launch it
• Click the button

Expected behavior
The following four message boxes should pop up:

• "It works if you capture something in the same function that you subscribe to changeButton.Click.0"
• "It works if we don't capture any values."
• "It doesn't work if we capture something.0"

Actual behavior
The last message in the list does not pop up.

Environment

• OS: Windows 10
• Version: 1903
• Devices tested: Microsoft Surface Go, Lenovo Thinkstation, and a crappy self-built PC I have at home.

Additional context
The original title of this issue was going to be "PropertyChanged events weaved by ReactiveUI.Fody in a .Net Core 3.0 WPF project do not get fired if the subscribed handler is a lambda expression that captures at least one value, UNLESS you also subscribe a different lambda to a completely unrelated button click event in the same function", but for some reason Github thought that was too long. I can't imagine why.

I really, REALLY need a drink after all of this.

[open-collective-bot]

Hey @ashelleyPurdue 👋,

Thank you for opening an issue. We will get back to you as soon as we can. Also, check out our Open Collective and consider backing us.

https://opencollective.com/reactiveui

PS.: We offer priority support for all backers. Don't forget to add priority label when you start backing us 😄

ReactiveUI - Open Collective

An advanced, composable, functional reactive model-view-viewmodel framework for all .NET platforms!

[glennawatson]

That's a really specific and quirky bug. Thanks for reporting it. Don't know what time line realistically we have for it being fixed at this stage but with the detailed report/repo at least we should be able to track it down.

[ashelleyPurdue]

I completely understand pushing it back. Priorities and all. There's also the possibility that the issue lies in .Net Core or Fody, not ReactiveUI(though I certainly hope that's not the case).

When .Net 5 rolls around and .Net Framework is deprecated, the problem is going to be more widespread as more projects start switching.

[mikant]

@ashelleyPurdue
My two cents
We've recently faced the exact same problem and quickly recognized the problem is with PropertyChangingEventManager that is used in ReactiveObjects for PropertyChanged subscriptions. That

#if NET_461

pragma doesn't get delivered in .net core 3 and an obsolete subscription scheme is used.
I've fixed this issue simply putting a custom ReactiveObject class in one of core projects of our solution:

namespace OurRootNamespace {
    public class ReactiveObject : ReactiveUI.ReactiveObject, IReactiveObject {
        public new event PropertyChangingEventHandler PropertyChanging;
        void IReactiveObject.RaisePropertyChanging(PropertyChangingEventArgs e) => PropertyChanging?.Invoke(this, e);

        public new event PropertyChangedEventHandler PropertyChanged;
        void IReactiveObject.RaisePropertyChanged(PropertyChangedEventArgs e) => PropertyChanged?.Invoke(this, e);
    }
}

and the problem has disappeared

[AgPeHaJIuH1]

Thanks a lot for your help. I already found the same solution in other open issues! =) пн, 9 дек. 2019 г. в 02:52, Mikhail Andreyev <notifications@github.com>:

…

@ashelleyPurdue <https://github.com/ashelleyPurdue> My two cents We've recently faced the exact same problem and quickly recognized the problem is with PropertyChangingEventManager that is used in ReactiveObjects for PropertyChanged subscriptions. That #if NET_461 pragma doesn't get delivered in .net core 3 and an obsolete subscription scheme is used. I've fixed this issue simply putting a custom ReactiveObject class in one of a core projects of our solution: namespace OurRootNamespace { public class ReactiveObject : ReactiveUI.ReactiveObject, IReactiveObject { public new event PropertyChangingEventHandler PropertyChanging; void IReactiveObject.RaisePropertyChanging(PropertyChangingEventArgs e) => PropertyChanging?.Invoke(this, e);` public new event PropertyChangedEventHandler PropertyChanged; void IReactiveObject.RaisePropertyChanged(PropertyChangedEventArgs e) => PropertyChanged?.Invoke(this, e); } } and the problem has disappeared — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2114?email_source=notifications&email_token=AHBRYGJYPUCH7O3B2FEVEVLQXWCCFA5CNFSM4H5A6IJKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGHOCFA#issuecomment-563011860>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHBRYGPNX56MIQUANMQ5QHLQXWCCFANCNFSM4H5A6IJA> .

[mikant]

@AgPeHaJIuH1
FYI #2276

"coincidence? I don't think so"
( for those who for a some mysterious reason doesn't understand russian yet :)

[ashelleyPurdue]

@ashelleyPurdue
My two cents
We've recently faced the exact same problem and quickly recognized the problem is with PropertyChangingEventManager that is used in ReactiveObjects for PropertyChanged subscriptions. That

#if NET_461

pragma doesn't get delivered in .net core 3 and an obsolete subscription scheme is used.

That...is hilarious! Thank you for digging into this!

[glennawatson]

Based on the discussion in this topic I believe #2276 should of solved this. Feel free to comment if it still happens.