inicio mail me! sindicaci;ón

Oh no, not AG_E_PARSER_UNKNOWN_TYPE!

You are coding an UserControl for your Silverlight 2 application that might change the world. You are almost done with it, already told all the guys that the first round is on you. You are thrilled about your fabulous coding skills.

And then you find him. An horrendous, terrible, dreadful enemy. His name: AG_E_PARSER_UNKNOWN_TYPE.

You don't want to cross his path.

You start looking for reasons of such an error, but all you find is despair. No hints, no clues, you start loosing your temper – and possibly your hair. You curse the framework for not supplying you with enough information: just a plain AG_E_PARSER_UNKNOWN_TYPE on your xaml file. Googling does not help you much, as few have faced that horrible vilain.

Fear not, friend, as I have found him myself, and I am going to share the secrets of some of his weak spots. Explore them, and I hope you defeat him the way I did.

Jokes apart, that was an error that took me a while to figure it out. Everything happened when I was creating user controls that were related to each other by their parent class. And impressively I run into two different situations in the same task that lead me to AG_E_PARSER_UNKNOWN_TYPE.

My solution was structured as follows:

using System;
using System.ComponentModel;

namespace MySolution
{
    public abstract class MyBaseClass : UserControl
    {
    }

    public partial class MyClass1 : MyBaseClass
    {
    }

    public partial class MyClass2 : MyBaseClass
    {
    }
}

First error in the intended code above: the MyBaseClass derivating from UserControl can’t be declared abstract. I know, it is a pain in case you want to create an abstract method within – you won’t be able to do that at all. Try a workaround like creating virtual methods throwing a NotImplementedException, and then overriding it with the real implementation.

The other situation I found that error in was related to listeners and the user control constructor. I’m not entirely sure why that happens, but if you register for a listener on the constructor class (or call any method registering it from the constructor) of your user control, you might have a chance to encounter the might evil AG_E_PARSER_UNKNOWN_ERROR is.

Also, a collegue pointed out for me a blog post with some explanations to AG_E_PARSER_UNKNOWN_ERROR and other Silverlight hell minions alike. Despite being related to Silverlight 1.1 alpha, I found the list to be trully helpful. I wish I had found that one before, the struggle would be much smaller!

Ouvindo: Deluxe Trio – Mais Pimenta Menos Sal

Frik Stuart said,

May 4, 2009 @ 5:37 AM

Thanks for the post! Saved me a lot of pain, was ready to pull my hair out after an hour of trying to debug and figure out what’s going on.

Däään said,

April 1, 2010 @ 10:39 PM

In my case it was Silverlight 3 and a labels’ x:name tag containing a special character…

> Nope!

> Better…

xelx said,

April 26, 2010 @ 11:32 AM

Same happens if one is stupid like me and tries to place a selfmade UserControl in the xaml of another control.. forgetting that there is no paramterless constructor for the selfmade one ;)
A bit of information from the compiler would be nice here

pmgnet said,

May 10, 2010 @ 12:04 AM

xelx, that was exactly my issue. Thanks!

Mike said,

August 13, 2010 @ 1:51 PM

Thanks much! In addition to helping point out the problem within a few minutes, you also nudged my frown a bit upward.

It’s kind of rediculous that we can’t add handlers for dynamic controls in the constructor–or any sub-methods.

RSS feed for comments on this post · TrackBack URI

Leave a Comment