Volendo utilizzare in XAML un proprio tipo, quello che dobbiamo fare è importare il namespace che lo contiene cosi che il compilatore possa riconoscerlo.
Esempio pratico: Se l'eseguibile referenzia un assembly che contiene una classe MyTextBox:.

   1:  namespace Controls
   2:  {
   3:    public class MyTextBox:TextBox
   4:    {
   5:      public MyTextBox (): base()
   6:      {
   7:        base.Background = Brushes.Yellow;
   8:      }
   9:    }
  10:  }

Una volta referenziata l'assembly MDLib che la contiene è possibile utilizzare MyTexbox direttamente in XAML scrivendo:.

   1:  Window x:Class="WPF1.Window1"
   2:      xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   3:      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
   4:     xmlns:my="clr-namespace:Controls;assembly=MDLib"
   5:      Title="WPF1" Height="300" Width="300"
   6:      >
   7:      <Grid>
   8:       <my:MyTextBox Width="100" Height="50" />        
   9:      </Grid>
  10:  </Window>

Però in questo caso ho legato nello XAML sia il namespace che l'assembly che contengono il tipo MyTextbox e sopratutto: perchè la sintassi è diversa rispetto ai namespaces predefiniti di WPF?
Il motivo è semplice: Volendo posso utilizzare un attributo XmlnsDefinition per reindirizzare un xml namespace verso un ben preciso clr-namespace.
Aggiungendo nella libreria questo attributo:

   1:  [assembly: XmlnsDefinition("http://www.manageddesigns.it/wpf/controls", "Controls")]

Posso utilizzare il nuovo xmlnamespace in sostituzione del precedente,ovvero:.

   1:  <Window x:Class="WPF1.Window1"
   2:      xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
   3:      xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
   4:     xmlns:my="http://www.manageddesigns.it/wpf/controls"
   5:      Title="WPF1" Height="300" Width="300"
   6:      >
   7:  ...
   8:  </Window>

Va detto che l'attributo funziona solo se i tipi stanno in assembly separate per un problema legato all'ordine di compilazione dello XAML. (dettagli)
Lo stesso attributo, utilizzabile anche in Workflow Foundation con la differenza che sta in System.Workflow.ComponentModel.Serialization non soffre invece di questa limitazione.