When working with different .NET technologies it is often good practice to extend a number of bases classes for your own requirements. There are couple of benefits for doing this.
- The derived classes provide a layer of protection/abstraction from the core framework so that changes can be managed more effectively.
- The derived classes provide the ability for you to extend base behaviour and share that throughout your application.
- You can increase testability.
Generally, when starting a new development, I like to do some of this infrastructure work upfront, this saves me a lot of refactoring down the line when I realise I need to extend a base class. Following this approach is particularly useful when working with .NET UI technologies such as WinForms, ASP.NET and WPF which implement a number of base classes upon which the majority of UI components are based.
Below is an example of the standard WinForms model whereby each Form is derived from System.Windows.Forms.Form versus the model I implement when I intend to extend the base Form class.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows.Forms;
namespace Extended.Base.Example
{
public class FormEx: Form
{
}
Our StandardForm implementation
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;
namespace Extended.Base.Example
{
public partial class StandardForm : FormEx
{
public StandardForm()
{
InitializeComponent();
}
}
All this works fine and you can compile and run the application. WinForms will not care if we have extended System.Windows.Forms as long as we still have the class in our inheritance hierarchy and it adheres to the same contract.
Now I am currently working on a WPF XBAP application and I want to use the same pattern within the world of WPF. You would imagine that this should be a fairly simple task. Each Page derives from System.Windows.Control.Page and User controls derived from System.Windows.Controls.UserControl. Therefore, it would seem logical that all that is required is to create a number of new classes that inherit the appropriate base class and then allow our new pages/controls to inherit from these. Below is some simple code to reflect this approach in an XBAP.
Our new derived Page Class
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows.Controls;
namespace Demo
{
public class PageEx: Page
{
}
}
A XAML page inheriting our extended class.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Data;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Imaging;
using System.Windows.Navigation;
using System.Windows.Shapes;
namespace Demo
{
///
/// Interaction logic for Page1.xaml
///
public partial class Page1 : PageEx
{
public Page1()
{
InitializeComponent();
}
}
}
And the XAML for our Page
<Page x:Class="Demo.Page1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="Page1">
<Grid>
Grid>
Page>
All we should need to do now is compile and run our application. If we do this, we notice that it’s not going to be as simple as we thought. Below is an error displayed from Visual Studio 2008.
The “Partial declarations of 'Your Type' must not specify different base classes” message is a standard compiler message that you can get whenever you implement a class using partial class files and then forget to may sure they all derive from the same base class. At first this error message seems a little odd as you only have one class in your solution window and that’s correctly deriving from PageEx.
The reason you encounter this error is due to the fact that WPF pages and controls have an auto generated file which is created by the compiler. This code is used for initialising the XAML document as some other gubbings. Therefore we need to update this file to ensure it reflects our new base class. If you want to see this class all you need to do is place the cursor on the InitializeComponent, right click and then choose “Goto Definition”. Doing this will be present you with the following.
So now we can see where our problem is, we can update the generated file to the following.
public partial class Page1 : PageEx, System.Windows.Markup.IComponentConnector
If you go about running the application the application runs with no problems. But this is not the end of the story. After working elsewhere in your application you may find that all of sudden the issue of partial classes returns. Looking at the generated file you will notice that it has regressed back to inheriting from System.Windows.Controls.Page.
When I first encountered this I scratched my head for a little and performed a few google searches. I eventually found that the problem was not related to generated file but that my XAML also needed to amended to reflect the extended base class. Below is the updated XAML file which shows my new XAML.
<local:PageEx x:Class="Demo.Page1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="clr-namespace:Demo"
Title="Page1">
<Grid>
Grid>
local:PageEx>
The first step is to import the namespace where your extended Page class resides.
xmlns:local="clr-namespace:Demo"
Then we need to update our Pages opening and closing tags to reflect the new type using the namespace alias we defined. In this case called local
<local:PageEx x:Class="Demo.Page1"
Now if you run the application you will no longer receive the “Partial Class” error and you can get onto the fun stuff! You will also need to use the same approach if you plan to extend other WPF base classes.