Style TargetType causes XamlParseException when not attached to debugger

Question

I have a very simple set of styles that I'm using in a couple of different WPF applications. I have this style stored in a Xaml file in a common project, then added by merging into the Resources in App.xaml in each of the projects.

<ResourceDictionary xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
                    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
                    xmlns:dxe="http://schemas.devexpress.com/winfx/2008/xaml/editors"
                    xmlns:i="clr-namespace:System.Windows.Interactivity;assembly=System.Windows.Interactivity">
    <Style TargetType="dxe:ComboBoxEdit">
        <Setter Property="AutoComplete" Value="True" />
        <Setter Property="IncrementalFiltering" Value="True" />
        <Setter Property="ImmediatePopup" Value="True" />
        <Setter Property="IsTextEditable" Value="True" />
        <Setter Property="ClearSelectionOnBackspace" Value="True" />
    </Style>
    <Style TargetType="dxe:ComboBoxEditSettings">
        <Setter Property="AutoComplete" Value="True" />
        <Setter Property="IncrementalFiltering" Value="True" />
        <Setter Property="ImmediatePopup" Value="True" />
        <Setter Property="IsTextEditable" Value="True" />
    </Style>
</ResourceDictionary>

Unfortunately, something about this is causing a XamlParseException regarding the TargetType property, but only when not attached to the debugger. If I start the application in the debugger, everything is fine. If I "Start Without Debugging", I get this as App.xaml is being loaded:

System.Windows.Markup.XamlParseException: 'Failed to create a 'TargetType' from the text 'dxe:ComboBoxEdit'.' Line number '5' and line position '12'. ---> System.Xaml.XamlParseException: Type reference cannot find type named '{http://schemas.devexpress.com/winfx/2008/xaml/editors}ComboBoxEdit'.
   at MS.Internal.Xaml.Context.ObjectWriterContext.ServiceProvider_Resolve(String qName)
   at MS.Internal.Xaml.ServiceProviderContext.System.Windows.Markup.IXamlTypeResolver.Resolve(String qName)
   at System.Xaml.Replacements.TypeTypeConverter.ConvertFrom(ITypeDescriptorContext context, CultureInfo culture, Object value)
   at MS.Internal.Xaml.Runtime.ClrObjectRuntime.CreateObjectWithTypeConverter(ServiceProviderContext serviceContext, XamlValueConverter`1 ts, Object value)
   at MS.Internal.Xaml.Runtime.ClrObjectRuntime.CreateFromValue(ServiceProviderContext serviceContext, XamlValueConverter`1 ts, Object value, XamlMember property)
   at System.Xaml.XamlObjectWriter.Logic_CreateFromValue(ObjectWriterContext ctx, XamlValueConverter`1 typeConverter, Object value, XamlMember property, String targetName, IAddLineInfo lineInfo)
   --- End of inner exception stack trace ---
   at System.Windows.Markup.XamlReader.RewrapException(Exception e, IXamlLineInfo lineInfo, Uri baseUri)
   at System.Windows.Markup.WpfXamlLoader.Load(XamlReader xamlReader, IXamlObjectWriterFactory writerFactory, Boolean skipJournaledProperties, Object rootObject, XamlObjectWriterSettings settings, Uri baseUri)
   at System.Windows.Markup.WpfXamlLoader.LoadBaml(XamlReader xamlReader, Boolean skipJournaledProperties, Object rootObject, XamlAccessLevel accessLevel, Uri baseUri)
   at System.Windows.Markup.XamlReader.LoadBaml(Stream stream, ParserContext parserContext, Object parent, Boolean closeStream)
   at System.Windows.Application.LoadComponent(Object component, Uri resourceLocator)
   at Shell.App.InitializeComponent() in c:\DevProjects\CoreApplication\Shell\App.xaml:line 1
   at Shell.App.Main() in C:\DevProjects\CoreApplication\Shell\obj\x86\Debug\App.g.cs:line 0

If I comment out both Style nodes, then everything works correctly. Any ideas?

Do you put your custom control's styles inside Themes/Generic.xaml? — Justin XL, Dec 08 '11 at 23:00
Well, a Xaml file can be anything, it's not clear to me what you're using. — Justin XL, Dec 09 '11 at 00:18
@Xin: It's in a file I created called "Styles.xaml" that is in a project that is shared. — Adam Robinson, Dec 09 '11 at 02:07
From your code I see you are trying to create default styles for your custom controls. You need to put them in a folder named 'Themes' and name it 'Generic.xaml'. Please take a look at this post. http://stackoverflow.com/questions/1228875/what-is-so-special-about-generic-xaml — Justin XL, Dec 09 '11 at 02:45
@Xin: Those are not custom controls; they're part of the DevExpress WPF toolset. I am trying to apply a default style to those two objects throughout my application. — Adam Robinson, Dec 09 '11 at 03:07

David · Accepted Answer · 2016-03-14T13:56:29.123

I had the same kind of issue, and for me it was the way the resource files were added to the project.

I had to make sure each and every one of my xaml style resource files were set up as "Page" (in the "build action" property). By default, they were not all in this mode (some as "Content", other as "compile" or "embedded resource" or "resource") and that caused this kind of issue.

maybe it's the same for you...

edit : from what I could gather, it has something to do with how the xaml code is embedded in the project and specifically the Order in which it is parsed by WPF: if the source file is set as "Page", the order in which the dictionary are merged is not taken into account, so this would work in release mode:

<Application.Resources>
    <ResourceDictionary>
        <ResourceDictionary.MergedDictionaries>
            <!-- let's say this dictionary contains a call to "MyButtonStyle" ... -->
            <ResourceDictionary Source="resources/Common.xaml" />
            <!-- ... and this one contains the definition of "MyButtonStyle" -->
            <ResourceDictionary Source="resources/GeneralResources.xaml" />
        </ResourceDictionary.MergedDictionaries>
    </ResourceDictionary>
</Application.Resources>

but this would not work with the other options (not all of them anyway, I did not try every single one of them) since the call would be parsed before the definition.

As to why it works in debug mode and not in release (or in your case when you start without debug), I guessed it was because WPF parses and stores resources into memory differently depending on the mode you're in (debug or not). I think WPF stores everything in memory in debug mode while it only stores what it needs in release mode (so for instance the calling code and not the definition code), but then again, it's just my guess...

edit 2: for me it was a nightmare to debug because it was even worse: it worked in some release configurations and not others because depending on the order of the actions taken by the user, he would get the error or not (the resource might already have been charged in memory or not when called, depending on what WPf already needed at this point), and of course I could not "debug" per say, since the debug mode always worked... It took me a while before figuring this solution out... glad it helped

Nice call! That solved the issue. To be fair, though, I did state in the bounty description that I wanted an explanation of *why* it's this way; any ideas? — Adam Robinson, Dec 09 '11 at 13:33
see my edit, but as written, nothing is proven, it's just what I deduced :) — David, Dec 09 '11 at 13:56
Thanks; it's not quite in line with my experience (I never actually built in release mode, it was always compiled in debug mode and would work with the debugger *attached* but not with it *detached*). In any case, that's as good of an explanation as I've been able to find, so I'll award the bounty when the timer's up (~5 minutes from now) — Adam Robinson, Dec 09 '11 at 14:25
wow that was an easy fix. I was optimistic and upvoted it before I tested it and sure enough it worked :-) — Simon_Weaver, Feb 08 '12 at 06:25
You saved me quite a lot of time ! Thanks a lot ! And I can confirm... the order of declaration is very important. Don't try to use something that has not yet been declared. — Eric Ouellet, Mar 07 '12 at 19:13
Man, I love you right now. Couple hours of research... this solved my issue. Errr! Had set to "Resource" on all my merged dictionaries. +1 for me man... Thanks! — TravisWhidden, Dec 26 '12 at 17:22
This worked for me as well, thanks. Ironically I discovered something very similar in the past and when I read your answer it was Déjà vu. Specifically, the build action of Resource also throws a XamlParseException when using x:Shared. Here's the [connect bug](https://connect.microsoft.com/VisualStudio/feedback/details/776631/using-x-shared-in-a-resourcedictionary-prevents-you-from-setting-the-file-build-action-to-resource), which the WPF team closed because they will not be addressing it. — Adam Caviness, Mar 19 '13 at 19:25

score 4 · Answer 2 · answered Sep 13 '12 at 00:14

For me what worked was a little different. I did already set the build action to 'Page', but any directories I had to remove. Example:

   <ResourceDictionary Source="resources/Common.xaml" />

would become

   <ResourceDictionary Source="Common.xaml" />

Of note, I was linked files since I was sharing them with silverlight

score 1 · Answer 3 · answered Dec 09 '11 at 10:33

1

Do you have reference to devexpress dlls in the project which has app.xaml.cs ? if not try by adding reference..

Also check the assembly loading by using the fuslogvw.exe and make sure the devexpress dlls are loaded.

answered Dec 09 '11 at 10:33

Joy George Kunjikkuru

1,495
13
27

I haven't tried your second step, but yes, the both the common project (which has the Xaml file) and the main project (with App.xaml) have references to the DLL's that contain these objects. – Adam Robinson Dec 09 '11 at 13:14
+1 for being a good idea, but the other answer solved my problem. Thanks! – Adam Robinson Dec 09 '11 at 13:34

score 0 · Answer 4 · edited May 23 '17 at 12:18

I was getting a XamlParseException with the message "Failed to create a 'Type' from the text 's:ScatterViewItem'", but only when running the application directly, not from the Visual Studio debugger.

This external answer told me that, for whatever reason, the necessary assembly hadn't been loaded yet. This StackOverflow answer showed me how to create a Main() function for my WPF app. I simply put "new ScatterViewItem();" at the top of my Main(), and the problem went away!

I have no idea what's going on here, especially since the ScatterViewItem is enclosed by a ScatterView from the same assembly. It sure sounds like a nasty bug in XAML parsing.

Style TargetType causes XamlParseException when not attached to debugger

4 Answers4

Linked