The XamlParseException AG_E_PARSER_BAD_TYPE checklist
While running a Silverlight application, you might sometimes encounter the dreaded runtime ParseException(“AG_E_PARSER_BAD_TYPE”). Despite its rather crude description, the message actually means something close to the words it uses: during the XAML parsing phase something went wrong with a type.
Here is a checklist I use to hunt down the cause for this exception:
- If you recently renamed a XAML file, check that its x:Class attribute matches the one in the associated code-behind file
- For every prefixed declaration in your XAML file, check that the XML namespaces match the correct assemblies
- Verify that your project references the assemblies used by the objects declared in your XAML files ("Add reference..."), and that these assemblies are present in the destination XAP files (use your favorite archiver, or change the XAP’s extension .ZIP and explore)
- Verify the value for the Copy local property of the assemblies referenced by your project’s XAML files, so that the assemblies are loaded by at least one project at runtime
- When using Prism, making your shell reference your assemblies (like the Silverlight Toolkit) can sometimes solve the issue. While making your shell reference every dependency your modules use definitely goes against the composite philosophy, referencing controls assemblies is usually a good idea.
- If all else fails, you can David Yack’s tip: force an instantiation of the type that causes the error in the constructor, prior to calling the InitializeComponent method
As you might have noticed, the cause for this exception usually comes down to a failure in type resolution. So make sure your referenced assemblies are available at runtime and you should be set.