How do I make custom XAML and CS partial classes with inheritance?

Question

I have researched this pretty thoroughly and found this, this, and this. All of the help pages that I've found say pretty much the same thing. It's not very complicated, so I'm pretty sure I've done it right but that the behind the scenes files are getting all confused or something. Any of the following three errors show up, and only errors 1 and 2 keep it from running.

Error 1: If an XAML files is open in the editor when I run it, then the error on only that file is: The name "Option" does not exist in the namespace "clr-namespace:Addin"

Error 2: If the XAML files are not open in the editor when I run it, then the error is: The type name 'Option' does not exist in the type 'Addin.Addin'. ...on all of the g.cs files.

Error 3: Exactly the same as 1, but on a different object. When I run it, it does resolve, causes no errors, and works exactly as it is supposed to.

Its as if VS is convinced that the class doesn't exist but only really cares when inheritance is involved.

Suffice it to say that I am confused and any insight as to what might be wrong would be greatly appreciated. Also, I am using VS 2012 Professional, which a few of my coworkers seem to think is the culprit of at least Error 3.

EAC1O1.xaml.cs

namespace Addin
{
    public partial class EAC1O1 : Option
    {
        public EAC1O1()
        {
            InitializeComponent();
        }
    }
}

Option.cs

namespace Addin
{
    public abstract class Option : UserControl
    {

EAC1O1.xaml

<local:Option x:Class="Addin.EAC1O1"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
              xmlns:local="clr-namespace:Addin"
             mc:Ignorable="d" >
    <DockPanel>

    </DockPanel>
</local:Option>

EAC1O1.g.cs

namespace Addin{


    /// <summary>
    /// EAC1O1
    /// </summary>
    public partial class EAC1O1 : Addin.Option, System.Windows.Markup.IComponentConnector {

.cs and .xaml files that are inherited from the abstract class Option (which has many properties and methods that apply to those classes that implement them) but in themselves NEED to be in different files as they are very different and complex GUIs, with Option being inherited from UserControl. Simple really. :) — unwrittenrainbow, Jul 17 '13 at 16:46
Dude, you are putting logic and functionality in the View, where it does `not` belong. Please show what you're trying to achieve here and I can tell you the proper way to do it in WPF. — Federico Berasategui, Jul 17 '13 at 16:48
There is a fullscreen GUI Window that, through a bunch of unrelated GUI controls, will eventually show the user one of thousands of UserControls. Each one is a calculator for very complex data, and they can vary drastically in design, data type, and functionality. Thus the need for separate files that can be coded in the designer and then just plugged in. However, they all have a few properties in common, GetPoints() or .CalcName for instance. Unless I'm missing something, the only logic/functionality in the view are those very few properties/methods that *all* calculators have in common. — unwrittenrainbow, Jul 17 '13 at 17:36
"which has many properties and methods that apply to those classes that implement them" ...was probably a source of confusion. I should have said a few. — unwrittenrainbow, Jul 17 '13 at 17:38
@unwriteenrainbow no of course not. You don't put any properties in the UI in WPF. You use DataTemplates, ViewModels and proper DataBinding. Read up on MVVM. — Federico Berasategui, Jul 17 '13 at 19:25
Well, it works beautifully now that I've found the solution, as posted. There really isn't any logic or code in the view parts and from a few colleagues reviews, it does follow MVVM. Maybe I'm just not explaining it correctly. Thanks for your help though. — unwrittenrainbow, Jul 17 '13 at 22:23

score 0 · Answer 1 · answered Jul 17 '13 at 02:12

0

You might try making your base Option class not be abstract. Parts of the designer rely on being able to create an instance of the class and/or base class being used in the XAML tags.

answered Jul 17 '13 at 02:12

John Bowen

24,213
4
58
56

It's a good thought, but no bueno. No change in behavior at all. I lost the designer a while ago, and that isn't my chief concern. Each of the instantiated Option classes can be designed as a dummy UserControl and then copy/pasted into the appropriate .xaml/.cs files. – unwrittenrainbow Jul 17 '13 at 16:50

unwrittenrainbow · Accepted Answer · 2013-07-19T20:26:38.263

EDIT: Psych, its not a bug. (Well it could use some additional functionality to avoid it.) I had a class named the same thing as the namespace. This has never broken anything and it throws no warnings so I didn't realize that this was a no no. Changing the class name fixed it all. VS should really throw a warning if you do this so you know that it might break things.

The solution ended up being a bug in Visual Studio 2012. I've shown this via two methods.

Method One: I separated the Option class into a different assembly (class library) and it now works beautifully exactly as written, just changing the namespaces.

Method Two: A coleague set up the same project in MS VS 2010 and it worked perfectly as well.

MS VS BUG# 794312

How do I make custom XAML and CS partial classes with inheritance?

2 Answers2