AG_E_PARSER_BAD_TYPE Adding Silverlight Toolkit control to module

Dec 10, 2008 at 4:39 PM
Lost a few hours on this one... The fix - add a reference to Microsoft.Windows.Controls to your main (shell) project.

Blogged about HERE
Dec 13, 2008 at 8:55 PM
Edited Dec 13, 2008 at 8:56 PM
Hi Bill, this is actually related to the fact that you need to add the dll in the ModuleManifest.xaml, otherwise even if the toolkit is included in the XAP file when building the project, it cannot be loaded when the module gets initialized.
We have a backlog item to replace this ModuleManifest.xaml with the AppManifest.xaml that Silverlight already builds, to help keep in sync the files that are included in the XAP, with the ones in the manifest (no manually writing the manifest).
Although conceptually you are not packaging a full Silverlight Application, the AppManifest contains very similar information to what we currently store in the ModuleManifest.

I hope this helps clarifying the problem, and I hope you agree with replacing this hard-to-mantain ModuleManifest file.
Julian Dominguez

Dec 16, 2008 at 5:47 PM
@JulianDominquez, we're running into a similiar issue with calling WCF services from Modules - I have two questions but before I ask them.  The error follows:

Could not find default endpoint element that references contract 'EmployeeServiceDAL.IEmployeeService' in the ServiceModel client configuration section. This might be because no configuration file was found for your application, or because no endpoint element matching this contract could be found in the client element.

This time I was ready for it and simply added my EmployeeServiceDAL to the Shell (main) project and all was well.  

1.  I'm not well-versed with Manifest (or the concept) so please bear with me but where exactly is the ModuleManifest.xaml file you were referring to?   With SCSF I was content with having a reference to each module so I could bypass the "hard-to-maintain" manifest file for Click-Once deployment but for our Silverlight app I think I'd rather learn how to manage it so we don't have to add references so our app will load/run.

2.  How long is backlog?  Rough guestimate will do - I have to determine ROI for writing a utility we (the community) can use to "easily" develop our CompositeWPF/Prism apps.

Appreciate your time :)

Dec 16, 2008 at 6:09 PM
Hi Bill,
Are you using remote modules that are deployed as separate XAP files? I was assuming that you were doing this, but if you never created the ModuleManifest.xaml, this might not be the case.
Are you using modules that are statically referenced by the Shell project?
Please let me know me know so I can help you better.

As for the backlog, we plan on releasing at the end of January (it's an estimate and not an official fixed date), but we're close to feature complete, so we'll be prioritizing bugs higher soon.

Dec 16, 2008 at 7:46 PM
Hi Julian,  "remote modules" - looks like I overlooked an important part of the documentation....  I'll be reading up on "How to Prepare a Module for Remote Downloading" and trust my issues will clear up :)  

I appreciate your time and help! 

Dec 19, 2008 at 4:44 AM
@Julian,  it appears there "may" be an issue with WCF services called from modules; I'm being forced to add a Web Service reference to the main shell project for my application to run.   I had tried different variations of ModuleManifest.xaml to no avail (although I really don't have my brain around the need for it yet).

I'll keep trying and keep you posted - just in case you want to give it a whirl yourself (against the next release code) the following thread references a blog, video demo and source code (plug'n play): 
Jun 10, 2009 at 10:16 AM



I'm having the same issue and it drives me nut as I can't fix it :( 


I've added Microsoft.Windows.Controls to my main project (Shell) and even to the module project to make sure. I've also read that this dll was replaced by System.Windows.Controls so I've added that one too to both projects. Yet I'm still getting the exception 'System.Windows.Markup.XamlParseException: AG_E_PARSER_BAD_TYPE [Line: 13 Position: 70]


What else can I do ??



Jun 10, 2009 at 1:49 PM

Try setting an x:Name on one of the controls from the toolkit. This will automatically generate C# code that references the toolkit.

Sometimes, if you don't reference the types in a DLL from code and just reference it from XAML, when it get compiled into the XAP, it won't include these DLLs as an optimization, because it believes it is not being used.

Let us know if this solves the problem,


Jun 10, 2009 at 3:28 PM

Thanks a lot, that worked ! So much time wasted on this :-(


And the .dll to reference is not Microsoft.Windows.Controls but System.Windows.Controls.


Again, thank you.

Aug 25, 2009 at 2:53 AM
Edited Aug 25, 2009 at 3:02 AM

Thanks for the solution Julian, this caused me so many problems as well and as my code is so simple I'll post it here to help other newbies like me:

The trick was in following Julian's suggestion, in the following all I added was x:Name="test" and all my databindings came to life (I don't actually refer to test anywhere else, it just being there solved the issue)





xmlns:x="" Width="725">

<Grid x:Name="LayoutRoot">

<data:DataGrid x:Name="test" ItemsSource="{Binding}" AutoGenerateColumns="True" />



Thanks everyone, the earlier posts for giving me a glimpse of what the problem might be, and Julian for the Eureka!

Mar 4, 2010 at 7:08 PM

Thank you for the x:Name solution. It worked like a charm.

- Emil Ingerslev