Version 2.1.2 breaks auto-property constructor initialization

[cervengoc]

Hi, when I updated to version 2.1.2 our entire application broke because as it turned out, during the IL weaving the auto-property initialization in the constructor have been replaced by direct backing-filed assignments.Here is a short example code.

public class Model {
  public int Something { get; set; }

  public Model() {
    Something = 1;
  }
}

In the generated assembly the Something = 1 property assignment is turned into assigning the value 1 to the corresponding backing field.

Reverting to 1.53.0 the problem is gone.

Is this behavior by design? If so, I couldn't find any notes anywhere about such a breaking change.

[navozenko]

As far as I understand, this was done in version 2.1.2 to exclude the invocation of virtual methods from the constructor.
#253, #220

[distantcam]

How is this breaking for you? It should not be possible to attach to the PropertyChanged event until after the constructor has run.

…

On Wed, 28 Jun 2017 at 4:50 pm, Sergey Navozenko ***@***.***> wrote: As far as I understand, this was done in version 2.1.2 to exclude the invocation of virtual methods from the constructor. #253 <#253>, #220 <#220> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#265 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABPRn4AfpnekXvyn4EH8hwYmKBpcsTMaks5sIhPOgaJpZM4OHJ3Z> .

[navozenko]

@distantcam inside a class, there may be owned handlers that are necessary to ensure the consistent internal state of the instance. For example, the handlers can subscribe to events or recalculate the values of other properties. If the constructor does not call handlers, then the created instance may be in an inconsistent state.

It seems to me that version 2.1.2 is a mistakes that breaks the work of a large number of programs. In addition, the new behavior is confusing, unexpected and unobvious.

For example, next class don't work in v2.1.2:

[AddINotifyPropertyChangedInterface]
class Model
{
    public Model()
    {
        Foo = 1;
    }

    public int Foo { get; set; }
    public int FooPlus1000 { get; private set; }

    void OnFooChanged()
    {
        FooPlus1000 = Foo + 1000;
    }
}

[cervengoc]

@navozenko I totally agree, I think the idea is basically good, but this should definitely be some kind of explicitly opt-in feature if developers want to make use of it.

By the way, my scenario was exactly a kind of internal state management affecting lots of our view model classes` initial state.

[tom-englert]

#264 will now have the old behavior as default; suppressing property changes from within the constructor can be controlled by the new NotifyAutoPropertiesInConstructorAttribute

[Syn-McJ]

I guess this is also why x:Bind is broken: if you initialize your properties from constructor, x:Bind simply will not update UI anymore if it set one-way or two-way.

[SimonCropp]

ok for now i am reverting #253 until i have more time to revisit this

[SimonCropp]

pushed to nuget

[tom-englert]

@SimonCropp then please re-open #220.

[SimonCropp]

Done