Don't worry. Not everyone knows it...

While working on any XAML based app, first thing which comes into mind is Binding . There are lot many articles on what is Binding and how it works. Don’t worry, I am not going to repeat all that stuff again. But definitely, I would like to touch upon few things which are base of my today’s write-up. To make any property bindable or let’s say to propagate property change, we usually follow one of the below two options: Implement INotifyPropertyChanged interface or Create an event with name PropertyNameChanged Point to notice here is, both the above options will work only on instance properties. Now what if my property is Static??? INotifyPropertyChanged is not going to work for static properties. None of the above options will make x:Static extension work. What to do now ? No worries, all these hazards can easily be overcome when you will jump to .Net 4.5. Approach 1: Property specific static event for each and every static property Let’s have a look a

Overload resolution has always been an area of frequent attention for compiler team. So, once again there are some major changes done to make the compiler more intelligent. Let's have a look at the below snippet(picked from MSDN) first and try to predict the output: Output in Visual Studio 2010: ExampleMethod: p2 is object Output in Visual Studio 2012/13: ExampleMethod: p2 is string Explanation of code: In above code, there are two overloads with a difference of 3rd parameter params and bit a different ordering of parameters. Visual Studio 2010 picks the overload without params parameter whereas Visual Studio 2012 compiler is smarter and picks the overload which has more specific type. If all your overloads do precisely the same thing, then this change will not be a problem. But in other cases, it may lead to crashes or exceptions. So, going forward, be careful while offering method overloads.

As most of you are aware that there are lot of language and compiler changes has happened with recent release of .Net, but all the issues will not arise until and unless you are recompiling your code. Once you recompile your code, these changes will be introduced regardless of which framework you target. Today I am writing about one of these breaking changes happened in .Net 4.5.  With earlier framework, named and optional parameter concept was introduced and unfortunately it was implemented incorrectly. In essence, there was a issue with the evaluation order of named parameter and will occur only when you are using methods as an argument.  Let's have a look at this snippet taken from MSDN: Expected output: A C B Output in Visual Studio 2010: C B A Output in Visual Studio 2012/2013: A C B Hope by this time, you are convinced about this incorrectness.  Please note, here issue is with named parameters and has nothing to do with optional parameters. This iss