Question

I’m not even sure if this is even possible, but I’ve just started WPF development on a few new projects and tried to wrap up some common functionality by creating a mini-framework. Just things like exception handling and thread management.

What I would like to do is replace this line…

public partial class App : Application

with

public partial class App : MyFrameworkApplication

I’ve got the libraries set up and referenced, but I get an error regarding the ‘partially’ declared App class, presumably because it’s still referencing the old base class.

Any ideas? Thanks.

EDIT: @Jeff M: No, your solution didn’t work. I suspect because the MyFrameworkApplication is actually in a library and the z namespace declaration fails to recognise the library’s namespace. I’ve got it referenced in the App.xaml.cs, but the suspicious looking error is:

Error 3 Undefined CLR namespace. The 'clr-namespace' URI refers to a namespace 'MyLibraryNamespace' that is not included in the assembly.

I can circumvent the problem by creating a proxy class within the local namespace and having it derive from the library class…but it’s a bit smelly.

Answer 1

I suspect it’s because the the underlying XAML root is still an Application as opposed to MyFrameworkApplication. I’d guess the generated baml uses the root as it’s parent class. Try changing it to the appropriate names.

e.g.,

<z:MyFrameworkApplication x:Class="MyNamespace.App"
             ...
             xmlns:z="clr-namespace:MyNamespace">
    ...
</z:MyFrameworkApplication>

It seems my suspicions were correct.

From the docs in Code-Behind and XAML in WPF:

Code-behind, Event Handler, and Partial Class Requirements in WPF

• The partial class must derive from the type that backs the root element. (emphasis mine)
• Note that under the default behavior of the markup compile build actions, you can leave the derivation blank in the partial class
  definition on the code-behind side. The compiled result will assume
  the page root’s backing type to be the basis for the partial class,
  even if it not specified. However, relying on this behavior is not a
  best practice.
• The event handlers you write in the code behind must be instance methods and cannot be static methods. These methods must be defined by
  the partial class within the CLR namespace identified by x:Class. You
  cannot qualify the name of an event handler to instruct a XAML
  processor to look for an event handler for event wiring in a different
  class scope.
• The handler must match the delegate for the appropriate event in the backing type system.
• For the Microsoft Visual Basic language specifically, you can use the language-specific Handles keyword to associate handlers with
  instances and events in the handler declaration, instead of attaching
  handlers with attributes in XAML. However, this technique does have
  some limitations because the Handles keyword cannot support all of the
  specific features of the WPF event system, such as certain routed
  event scenarios or attached events. For details, see Visual Basic and WPF Event Handling.

The root application type in code-behind and in the xaml must agree.