Managing inherited dependency properties in WPF Exposing Inherited Members

I have a WPF Custom Control library (ContentToggleButton) and an app (spec) to test it. The Custom Controls, which derive from Presentation Framework elements, expose inherited properties as well as new properties to the consumer.

This means that the consuming app depends on the Framework Elements as well as the Custom Controls as shown by the four dependencies from the top and bottom of MainWindow in the following diagram.  



Reimplementing Inherited Members

The references were due to the IsChecked dependency property of the ToggleButton base class of the ContentToggle object and the Click event of the ButtonBase base class of the ButtonContent object. The former was bound in the XAML to a method on the MainWindow class in the View, code behind.



&lt;b:ContentToggle Name="Toggle" Height="30"
                 Options="{Binding ToggleButtonView.Options, 
                            RelativeSource={StaticResource View}}"
                 IsChecked="{Binding ToggleButtonView.InitialState,
                            Mode=OneWay,
                            RelativeSource={StaticResource View}}" /&gt;
&lt;b:ContentButton x:Name="Plain" Height="30" 
                 Options="{Binding PlainButtonView.Options, 
                            RelativeSource={StaticResource View}}" /&gt;


The RelativeSource resource is defined in Resource Dictionary in App.xaml. 

&lt;!--Get a reference to the window to establish View Context--&gt;
&lt;RelativeSource x:Key="View" Mode="FindAncestor" 
            AncestorType="{x:Type Window}" /&gt;


The second dependency was due to subscribing to the Click event inherited from ButtonBase in the MainWindow class.



Plain.Click += (s, e) =&gt; {
    Toggle.IsEnabled = !Toggle.IsEnabled;
};


By adding a custom DP called InitialState on ContentToggle and binding to that instead then using it to initialise IsChecked in the Loaded event, one of the dependencies was eliminated.

public static readonly DependencyProperty 
    InitialStateProperty = DependencyProperty.Register(
    "InitialState", typeof(bool?), typeof(ContentToggle), 
    new PropertyMetadata(false));

public bool? InitialState
{
    get { return (bool?) GetValue(InitialStateProperty); }
    set { SetValue(InitialStateProperty, value); }
}


The second dependency was eliminated by reimplementing the Click event in the custom property and routing the original event through it.

public static readonly RoutedEvent ClickEvent = EventManager.RegisterRoutedEvent(
    "Click", RoutingStrategy.Bubble, typeof(RoutedEventHandler), typeof(ContentToggle));

public new event RoutedEventHandler Click
{
    add { AddHandler(ClickEvent, value); }
    remove { RemoveHandler(ClickEvent, value); }
}

void RaiseClickEvent (object o, RoutedEventArgs e)
{
    RoutedEventArgs newEventArgs = new RoutedEventArgs(ContentToggle.ClickEvent);
    RaiseEvent(newEventArgs);
}
public ContentToggle()
{
    base.Click += RaiseClickEvent;

}


As a result, the consuming app is unaware of the primitive components with dependencies only on the CC Library.



Is this a good idea or a bad one? Is it worth the extra code?
Well, this looks like a really bad idea.


To begin with... what's the point? I mean what is so bad about having a dependency on standard .Net assembly? It is already installed on the machine as part of .Net installation, so this dependency does not affect the size of your app. Am I missing something?
This design works under fairly naive assumption, that the app will not change in any way as the time goes on. And it might be the case for your particular app, but it is not the case in general. Imagine I am using your library, and I want to subscribe to ContentToggle.Loaded event. What should I do? Should I call you at 3AM and ask you to also override this event with new keyword? Will you do the same thing for every single event (or property) found on FrameworkElement? Will you then test every single interaction, to make sure you did not break standard behavior? If you are not willing to take this all the way - don't do it at all.
I don't even want to begin imagining all the potential pitfalls. What will happen if someone sets e.Handled = true; for your new Click event? Will your base event keep going? What will happen, if I have a style for regular button that uses &lt;EventSetter Event="Click" .../&gt; and I want to override this setter for your button's style? How is it going to work, will I have two event handlers as a result or just one? Etc, etc.