WPF Bug : "assembly used when compiling might be different"
(Nov 06 2008 - 08:46:20 AM
by Timothy Khouri
) - [print blog
Recently, we made the switch at my job to use WPF for our Windows apps (and even for new User Controls in existing apps). I'm absolutely loving WPF, and all of it's goodness. There have been a few learning curves, but all in all it's been worth it.
Yesterday, however, I found my first "stupid bug" in WPF. A "stupid bug" is a bug that doesn't even begin to make sense. I've already seen a bug that was simply the mistake of the developer at Microsoft who made the 'GroupBox' control. (Thanks "Dr. WPF" for figuring that one out and fixing it.)
But this bug is beyond me as to why it happens. I can't even begin to understand who to blame on the WPF team for this one :)
How to Recreate the Bug
To see this bug for yourself doesn't take much. I simply downloaded the WPFToolkit from CodePlex, and tried to use the DatePicker. After referencing the DLL, everything looks great in the designer (and in the XAML). But, if I run my app, I get this error:
What's the problem you might ask? Quite stupidly... you'll get this error if you don't have a "Name" property on your control.
That's it! From what I've seen, if you add a reference to an assembly that has WPF controls in it... you can use those controls, but if you don't give them a Name, then at runtime, you'll get an error.
Horribly stupid bug... but, it is a very simple fix (just add a name)!
Show Me The XAML!
Here's the XAML that will error at runtime:
Here's the XAML that will not error at runtime:
<my:DatePicker Name="blahblah" />
By the way, to add to the stupidity of this bug, you only have to name *one* of your DatePicker controls. So, if you have two on the same XAML page, you only have to name one of them and you won't get the error.