I'm now in the thick of working on my company's major commercial application and am building some cool user controls.  I finally had the need to create some dependency properties on one of my controls today but at first I didn't understand why I had to do anything special beyond what I would do in the Winforms realm.  I wanted to hide or show a row in my grid so I simply created a public property ShowStatusRow that did this in code and all worked as expected.  The property even showed up in blend for me to set at design time and I was happy and could've (and maybe should've) gone on my merry way.  But I stopped for a question and asked the question...what is all this stuff I've heard about dependency properties?  I didn't even use them but they keep getting hyped up and written about on the net....obviously I missed something.  What exactly did a dependency property buy me over a standard property?

Well I've spent the better part of a day writing code to illustrate what it buys you.  There are plenty of technical explanations out there, but to keep it simple, here's what I found.  If you want to work with WPF usercontrols as you would have worked with winform user controls then regular properties will suffice.  You will get design time properties that appear in your IDE and can access the properties in your code behind as you would have in a traditional winforms app.  However, if you want to manipulate your controls on storyboards or with WPF data binding you have to use dependency properties. 

To illustrate what I found I created a sample project with 2 different user controls.  The controls just have a label on them with a boolean property that sets the visibility on the label.  On one of the controls the property is a traditional property (IsLabelVisibleRegular).  On the other control I used DependencyProperties (IsLabelVisibleDependency).  I then created a test form that utilizes these controls.
 

I used blend to play with the controls to see what the limitations were on a control with just a regular property vs one with a dependency property.  The difference is dramatic...in Blend, the only manipulation I could do to the control with the regular property was a global setting if the IsLabelVisible property.  I could not databind that property (the option was grayed out), and if I tried to do anything with that property on a storyboard it would apply the change I made to the property at the "global" level, not just limiting it to the timeline I was working on.  The only way I could manipulate the property at runtime was in code.

Contrast that to what I could do with my control that utilized the dependency property.  I could now databind the property to the IsChecked status of my toggle button.  I could also set its value in storyboards, and of course I could manipulate it in code just as I could a regular property.

I've attached my sample project.  It contains a clear example of the functional difference of a dependency property vs a standard property.  It is also useful for those looking for information on how to declare and use your dependency properties, how to call them in code, bind to them, and modify them on the storyboard in blend.  I also had to create a class that implements IValueCoverter as I wanted the label on the controls to be visible when the toggle buttons state was not checked and be visible when it was checked...so I had to flip the boolean to get the binding method to work correctly.  Sadly I couldn't find a built in way to do this in Blend so I had to write the BooleanFlipper class myself.

I hope this is useful to someone else out there!

PropertyTester.zip