Property Change Notification with Compile Time Safety

This would be less code and easier. You don't need to pass in the property name since System.Runtime.CompilerServices.CallerMemberName() will get it for you at run time.

C#

public string MyProperty {
    get { return MyPropertyField; }
    set {
        MyPropertyField = value;
        OnPropertyChanged();
    }
}
private string MyPropertyField;

protected void OnPropertyChanged([System.Runtime.CompilerServices.CallerMemberName()]
string propertyName = "")
{
      if (propertyName != null)
            {
                PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
            }
}

You don't even need .NET4.5, you can define CallerMemberName in your code and the compiler will do the rest.

You need the compiler that supports it, no?

Software Zen: delete this;

That is correct. You need the compiler but not .NET4.5.

Or use the next version of C#, allowing more complex scenarios.

C#

public string FirstName
{
   get { return this.firstName; }
   set
   {
      this.firstName = value;
      OnPropertyChanged(nameof(this.FirstName));
      OnPropertyChanged(nameof(this.FullName));
   }
}

The "static reflection" solution is hardly new. It's been posted to CodeProject before, not to mention in a zillion other places. It has some very real runtime overhead, though. The C# vNext solution is by far the best, though the CallerMemberName solution can simplify the 80% case in combination with the nameof solution for the 20% cases.

William E. Kempf

When compiling code using VS2010 and earlier System.Diagnostics.StackTrace does not work for release builds due to inlining & JIT optimisation.
This is a real bitch if you were using StackTrace to determine property names for auditing purposes.
Thankfully general stack tracing was sorted out in .Net4.5 and VS2012, however you lose the ability to determine property names.
Luckily there is a workaround, firstly you need to add the BCL components & portability pack, add using System.Runtime.CompilerServices; to your code, turn off inlining and then use the [CallerMemberName] attribute

The following code will work for both debug and release:

[System.Runtime.CompilerServices.MethodImpl(System.Runtime.CompilerServices.MethodImplOptions.NoInlining)]
protected void PropertyHasChangedExplicit([CallerMemberName] string propertyName = "")
{
if (propertyName == string.Empty)
{
propertyName = new System.Diagnostics.StackTrace().GetFrame(1).GetMethod().Name.Substring(4);
}
PropertyHasChanged(propertyName);
}

protected virtual void PropertyHasChanged(string propertyName)
{
ValidationRules.CheckRules(propertyName);
MarkDirty(true);
OnPropertyChanged(propertyName);
}

Hope this helps anyone else who is struggling with this problem

This doesn't make any sense. With CallerMemberName the propertyName string will only be empty (you really should use null here) if the caller specifically passes that value (and you WANT them to be able to do that to indicate all properties should be considered to have changed). Rather than dealing with StackTrace here, just don't do that. In any case, the NoInlining will prevent inlining of this method, but not the inlining of the properties, so this wouldn't fix the inlining issue in any case. You'd have to add NoInlining to every property, which makes a StackTrace solution a non-starter to me.

Remove the NoInlining attribute, change the default value of propertyName to null, ditch the StackTrace call, use .NET 4.5 or define CallerMemberNameAttribute (in the correct namespace) yourself and everything will "just work".

William E. Kempf

The code snippet I gave is for older versions of .Net & VS, we all know that you can use static reflection in .Net4.5 to achieve this. As VS is closely tied to versions of .Net it is difficult for smaller companies to afford the thousands of pounds to upgrade every 2 years. As I mentioned previously my example will work in debug from VS2010 onwards and in release from VS2012.

This still makes no sense.

1. CallerMemberName won't work in a compiler older than the one supplied in VS 2013, no matter how you define it.
2. Your use of CallerMemberName is confusing and seems to indicate you don't understand what it does. Maybe caused by the fact that you're trying to use it with an older compiler?
3. The NoInlining is still pointless here, and is necessary on every property if you're going use this solution.

You can use static reflection in any .NET version since 3.5. CallerMemberName isn't static reflection. Is that where the confusion is?

VS is not closely tied to versions of .NET. You can change the target framework while creating a project and change it after a project is made. That doesn't mean your point about upgrading isn't a concern, just that the concerns have more to do with compiler and IDE features than with framework concerns. What I find confusing is why you call this out in your reply, as I never disputed it?

Your example won't really work. That's why I'm confused. Maybe your intention was just to use CallerMemberName when compiling with a newer compiler and CallStack when not, but I question the need to support different compiler versions in your code base as well as the fashion in which you tried to do it. In any event, the solution is broken on any version of the compiler.

William E. Kempf

1. CallerMemberName comes in the BCL components & portability pack which you can use in VS2012.
2. & 3. You need to structure the code that way if you want to debug using VS2010 & release in VS2012.

I know exactly how it works, and have it working right here right now in a very large project I have been writing for over 3 years.

Instead of just dismissing suggestions out of hand, I suggest that you do what any decent software engineer would do and try it out.

Quit with the flames.

NoInlining tells the compiler not to inline *that method*. The issue with the StackTrace solution is not that the OnPropertyChanged method gets inlined in release builds, but that the property that calls it gets inlined. What you've written won't do anything about that, and you'll likely still have things not work as you expect it to in release builds.

CallerMemberName tells the compiler that if the user didn't supply a value, it should supply it with the name of the caller. The caller can pass the default value (either your empty string, or the preferred null), and that will be the value passed, but your code will turn around and try the alternate CallStack solution, entirely breaking valid functionality. So, while the vast majority of the time this may work, it's still broken code.

So, some of my confusion is cleared up. You've written this code so that it will "work" no matter which compiler you use, it just "works" in different ways. I don't know many people that need to target different compilers, but if that is a need, conditional compilation would be far preferred here.

William E. Kempf

I've used that technique for a long time now. I store the name in static readonly string variable once and use it to prevent the penalty of calling lambda expression again and again.

Is it worth saving couple microseconds (performance gain near 0%) for the price of code's clarity, cleanliness etc.?

If that decreases code clarity for you, don't use it! In my case it did make noticeable difference in hydrating large collections of objects with data.

We can do that, but would not be a scalable solution as the number of properties grow. Further, we would have to go and add a constant each time a property is added to the class. We are in effect doing the same, but using reflection. Not sure how much would be the performance impact though.

In my case, the code was being generated using templates so adding this was just a small change in template. If it does not suit your requirements, don't use it.

The overhead of "static reflection" is nearly identical to that of "runtime reflection". It's far from zero, though it is small enough to only be an issue in certain scenarios.

William E. Kempf

This framework has one-liner setter for WPF and Silverlight and another useful features

You dont need a framework for that, you just need a good base INPC class, something like this:

C#

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Diagnostics;
using System.Linq.Expressions;

using Moneycorp.Options.Client.ExtensionMethods;

namespace Moneycorp.Options.Client.ViewModel
{

    public class INPCBase : INotifyPropertyChanged
    {
        /// <summary>
        /// Warns the developer if this object does not have a public property with the specified name. This
        /// method does not exist in a Release build.
        /// </summary>
        [Conditional("DEBUG")]
        [DebuggerStepThrough]
        public void VerifyPropertyName(string propertyName)
        {

            // Verify that the property name matches a real,
            // public, instance property on this object.
            if (TypeDescriptor.GetProperties(this)[propertyName] == null)
            {
                string msg = "Invalid property name: " + propertyName;

                if (this.ThrowOnInvalidPropertyName)
                    throw new Exception(msg);

                Debug.Fail(msg);
            }
        }

        /// <summary>
        /// Returns whether an exception is thrown, or if a Debug.Fail() is used when an invalid property name is passed to the VerifyPropertyName method.
        /// The default value is false, but subclasses used by unit tests might override this property's getter to return true.
        /// </summary>
        protected virtual bool ThrowOnInvalidPropertyName { get; private set; }


        public event PropertyChangedEventHandler PropertyChanged;

        private void NotifyPropertyChanged(PropertyChangedEventArgs args)
        {
            PropertyChangedEventHandler handler = PropertyChanged;

            if (handler != null)
            {
                handler(this, args);
            }
        }

        //Used by code that may want to fire additional properties. For example
        //when there is only a getter available, but the UI still needs to be notified


        /// <summary>
        /// Used by code that may want to fire additional properties. For example
        /// when there is only a getter available, but the UI still needs to be n
        /// </summary>
        /// <param name="propertyName">Expression representing the property to use</param>
        public void RaisePropertyChanged<TValue>(Expression<Func<TValue>> propertySelector)
        {
            if (PropertyChanged != null)
            {
                NotifyPropertyChanged(new PropertyChangedEventArgs(propertySelector.GetPropertyName()));
            }
        }

        public TRet RaiseAndSetIfChanged<TRet, TValue>(ref TRet backingField, TRet newValue, Expression<Func<TValue>> propertySelector)
        {
            if (EqualityComparer<TRet>.Default.Equals(backingField, newValue))
            {
                return newValue;
            }

            backingField = newValue;
            RaisePropertyChanged(propertySelector);
            return newValue;
        }

        public TRet RaiseAndSet<TRet, TValue>(ref TRet backingField, TRet newValue, Expression<Func<TValue>> propertySelector)
        {
            backingField = newValue;
            RaisePropertyChanged(propertySelector);
            return newValue;
        }





    }
}

Which allows this:

C#

public bool IsSelected
{
    get { return this.isSelected; }
    set
    {
        RaiseAndSetIfChanged(ref this.isSelected, value, () => IsSelected);
    }
}

Which as you say is 1 line, and not a single framework in sight

Yeah, that's exact implementation. Your comment has more value than article itself.

Thanks for posting this implementation. Yes, generally a better approach is to have a common base class for your client side entities and the base class would then implement common interfaces/ functionalists we want to implement (this includes any custom validation, dirty tracking etc.)

what about this?

http://msdn.microsoft.com/en-us/library/system.runtime.compilerservices.callermembernameattribute(v=vs.110).aspx[^]

Please note that CallerMemberName was introduced with .Net 4.5 and wasn't available in earlier versions.

Although your statement is correct, CallerMemberName is backward compatible meaning that you can define the attribute in your code and the compile will handle the rest.

It's not a question of what framework you target, but of what compiler you use. You'll have to have VS2013 to use the CallerMemberName solution.

William E. Kempf

Property Change Notification with Compile Time Safety

Introduction

Background

Using the Code

License

Comments and Discussions