What's the difference between a dependency property and an attached property in WPF?

Question

What's the difference between a (custom) dependency property and an attached property in WPF? What are the uses for each? How do the implementations typically differ?

Answer 1

Attached properties are a type of dependency property. The difference is in how they're used.

With an attached property, the property is defined on a class that isn't the same class for which it's being used. This is usually used for layout. Good examples are Panel.ZIndex or Grid.Row - you apply this to a control (ie: Button), but it's actually defined in Panel or Grid. The property is "attached" to the button's instance.

This allows a container, for example, to create properties that can be used on any UIelement.

As for implementation differences - it's basically just a matter of using Register vs. RegisterAttached when you define the property.

Answer 2

Abstract

Since I found little to no documentation on the matter, it took some poking around the source code, but here's an answer.

There is a difference between registering a dependency property as a regular and as an attached property, other than a "philosophical" one (regular properties are intended to be used by the declaring type and its deriving types, attached properties are intended to be used as extensions on arbitrary DependencyObject instances). "Philosophical", because, as @MarqueIV noticed in his comment to @ReedCopsey's answer, regular properties can also be used with arbitrary DependencyObject instances.

Moreover, I have to disagree with other answers stating that attached property is "type of dependency property", because it's misleading - there aren't any "types" of dependency properties. The framework doesn't care if the property was registered as attached or not - it's not even possible to determine (in the sense that this information is not recorded, because it's irrelevant). In fact, all properties are registered as if they were attached properties, but in case of regular ones some additional things are done that slightly modify their behavior.

Code excerpt

To save you the trouble of going through the source code yourself, here's a boiled down version of what happens.

When registering a property without metadata specified, calling

DependencyProperty.Register(     name: "MyProperty",     propertyType: typeof(object),     ownerType: typeof(MyClass)) 

yields exactly the same result as calling

DependencyProperty.RegisterAttached(     name: "MyProperty",     propertyType: typeof(object),     ownerType: typeof(MyClass)) 

However, when specifying metadata, calling

DependencyProperty.Register(     name: "MyProperty",     propertyType: typeof(object),     ownerType: typeof(MyClass),     typeMetadata: new FrameworkPropertyMetadata     {         CoerceValueCallback = CoerceCallback,         DefaultValue = "default value",         PropertyChangedCallback = ChangedCallback     }); 

is equivalent to calling

var property = DependencyProperty.RegisterAttached(     name: "MyProperty",     propertyType: typeof(object),     ownerType: typeof(MyClass),     defaultMetadata: new PropertyMetadata     {         DefaultValue = "default value",     }); property.OverrideMetadata(     forType: typeof(MyClass),     typeMetadata: new FrameworkPropertyMetadata     {         CoerceValueCallback = CoerceCallback,         DefaultValue = "default value",         PropertyChangedCallback = ChangedCallback     }); 

Conclusions

The key (and only) difference between regular and attached dependency properties is the default metadata available through DependencyProperty.DefaultMetadata property. This is even mentioned in the Remarks section:

For nonattached properties, the metadata type returned by this property cannot be cast to derived types of PropertyMetadata type, even if the property was originally registered with a derived metadata type. If you want the originally registered metadata including its original possibly derived metadata type, call GetMetadata(Type) instead, passing the original registering type as a parameter.

For attached properties, the type of the metadata returned by this property will match the type given in the original RegisterAttached registration method.

This is clearly visible in the provided code. Little hints are also hidden in the registering methods, i.e. for RegisterAttached the metadata parameter is named defaultMetadata, whereas for Register it is named typeMetadata. For attached properties the provided metadata becomes the default metadata. In case of regular properties however, the default metadata is always a fresh instance of PropertyMetadata with only DefaultValue set (either from provided metadata or automatically). Only the subsequent call to OverrideMetadata actually uses the provided metadata.

Consequences

The main practical difference is that in case of regular properties the CoerceValueCallback and PropertyChangedCallback are applicable only for types derived from the type declared as the owner type, and for attached properties they're applicable for all types. E.g. in this scenario:

var d = new DependencyObject(); d.SetValue(SomeClass.SomeProperty, "some value"); 

the registered PropertyChangedCallback will be called if the property was registered as an attached property, but will not be called if it was registered as a regular property. Same goes to CoerceValueCallback.

A secondary difference stems from the fact that OverrideMetadata requires that supplied type derives from DependencyObject. In practice it means that the owner type for regular properties must derive from DependencyObject, whereas for attached properties in can be any type (including static classes, structs, enums, delegates, etc.).

Supplement

Besides @MarqueIV's suggestion, on several occasions I've come across opinions that regular and attached properties differ in the way they can be used in XAML. Namely, that regular properties require implicit name syntax as opposed to explicit name syntax required by attached properties. This is technically not true, although in practice it usually is the case. For clarity:

<!-- Implicit property name --> <ns:SomeClass SomeProperty="some value" />   <!-- Explicit property name --> <DependencyObject ns:SomeClass.SomeProperty="some value" /> 

In pure XAML, the only rules governing the usage of these syntaxes are the following:

• Implicit name syntax can be used on an element if and only if the class that this element represents has a CLR property of that name
• Explicit name syntax can be used on an element if and only if the class specified by the first part of the full name exposes appropriate static get/set methods (referred to as accessors) with names matching the second part of the full name

Satisfying these conditions enables you to use corresponding syntax regardless of whether the backing dependency property was registered as regular or attached.

Now the mentioned misconception is caused by the fact that vast majority of tutorials (together with stock Visual Studio code snippets) instruct you to use CLR property for regular dependency properties, and get/set accessors for attached ones. But there's nothing stopping you from using both at the same time, allowing you to use whichever syntax you prefer.