A StaticResource will be resolved and assigned to the property during the loading of the XAML which occurs before the application is actually run. It will only be assigned once and any changes to resource dictionary ignored.
A DynamicResource assigns an Expression object to the property during loading but does not actually lookup the resource until runtime when the Expression object is asked for the value. This defers looking up the resource until it is needed at runtime. A good example would be a forward reference to a resource defined later on in the XAML. Another example is a resource that will not even exist until runtime. It will update the target if the source resource dictionary is changed.
There really is only one name in XAML, the x:Name. A framework, such as WPF, can optionally map one of its properties to XAML's x:Name by using the RuntimeNamePropertyAttribute on the class that designates one of the classes properties as mapping to the x:Name attribute of XAML.
The reason this was done was to allow for frameworks that already have a concept of "Name" at runtime, such as WPF. In WPF, for example, FrameworkElement introduces a Name property.
In general, a class does not need to store the name for x:Name to be useable. All x:Name means to XAML is generate a field to store the value in the code behind class. What the runtime does with that mapping is framework dependent.
So, why are there two ways to do the same thing? The simple answer is because there are two concepts mapped onto one property. WPF wants the name of an element preserved at runtime (which is usable through Bind, among other things) and XAML needs to know what elements you want to be accessible by fields in the code behind class. WPF ties these two together by marking the Name property as an alias of x:Name.
In the future, XAML will have more uses for x:Name, such as allowing you to set properties by referring to other objects by name, but in 3.5 and prior, it is only used to create fields.
Whether you should use one or the other is really a style question, not a technical one. I will leave that to others for a recommendation.
See also AutomationProperties.Name VS x:Name, AutomationProperties.Name is used by accessibility tools and some testing tools.
Best Answer
In practice custom controls are something you implement on the code level while you can use XAML for user controls. The custom controls extend one of the WPF control base classes and provide additional functionality through code so all the added logic and representation must be implemented inside the code.
A user control is technically a normal content control which you can extend in some parts in the code but usually it is extended by placing other controls inside it. So as Kent mentioned a UserControl is an aggregation of other controls. This limits what you can do with a user control considerably. It's easier to use but more limited than a full custom control.
These controls have a small difference from a runtime point of view. When building an application and placing an UserControl into it, the control tree will have a concrete UserControl template inside of it. So if we consider a lame example of a specialized button. If you were using a user control you'd add a button inside the
<UserControl>element. When using a custom control you'd derive the control itself from a button most likely. The difference would be visible in the logical tree.While the custom control would provide a logical tree similar to
The UserControl would give a logical tree of
So in the end the UserControl is just a normal ContentControl which you can extend a bit and for which you can predefine the content. Custom control provides greater flexibility at the price of ease of implementation as you have to do all the logic and interaction in the code instead of having the benefit of XAML.
Though after all this, I don't think there's that much difference in the Visual Studio templates. Most likely the Visual Studio Custom Control just creates a project with an empty custom control while the User Control project is a project with an empty user control. You can later add any kind of items to the project.
Update
And my opinion on when to use custom control and user control is that if you can get something done with a user control and the extra control element in the logical tree doesn't bother you, use a user control as they are so much easier to create and maintain. Use a custom control only if you have a reason not to use a user control.