One Dev Job

Yesterday I got one of those XamlParseExceptions that do not seem to make sense. It happened after I moved most of the code from my Windows Phone application to a class library. In fact the only things I left in the application project were the App class, the Properties folder and some resources that differentiate different applications that share the library. If you want to do something similar – you can have your MainPage class defined in a library and just need to update the WMAppManifest.xml to point at its new location, eg: NavigationPage=”MyClassLibrary;component/Pages/MainPage.xaml”.

Everything worked fine except for this bit:

<i:Interaction.Triggers>
    <ic:PropertyChangedTrigger
        Binding="{Binding PageNumber}">
        <im:ControlStoryboardAction
            ControlStoryboardOption="Play">
            <im:ControlStoryboardAction.Storyboard>
                <Storyboard>
                    <DoubleAnimation ...

It kept throwing an exception:

System.Windows.Markup.XamlParseException occurred
Message=Unknown parser error: Scanner 2147500037. [Line: 82 Position: 41]
LineNumber=82
LinePosition=41
StackTrace:
at System.Windows.Application.LoadComponent(Object component, Uri resourceLocator)
at MyClassLibrary.View.BookPageView.InitializeComponent()
at MyClassLibrary.View.BookPageView..ctor()
at System.Reflection.RuntimeConstructorInfo.InternalInvoke(RuntimeConstructorInfo rtci, BindingFlags invokeAttr, Binder binder, Object parameters, CultureInfo culture, Boolean isBinderDefault, Assembly caller, Boolean verifyAccess, StackCrawlMark& stackMark)
at System.Reflection.RuntimeConstructorInfo.InternalInvoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, StackCrawlMark& stackMark)
at System.Activator.InternalCreateInstance(Type type, Boolean nonPublic, StackCrawlMark& stackMark)
at System.Activator.CreateInstance(Type type)
at System.Windows.Navigation.PageResourceContentLoader.BeginLoad_OnUIThread(AsyncCallback userCallback, PageResourceContentLoaderAsyncResult result)
at System.Windows.Navigation.PageResourceContentLoader.c__DisplayClass4.b__0(Object args)
at System.Reflection.RuntimeMethodInfo.InternalInvoke(RuntimeMethodInfo rtmi, Object obj, BindingFlags invokeAttr, Binder binder, Object parameters, CultureInfo culture, Boolean isBinderDefault, Assembly caller, Boolean verifyAccess, StackCrawlMark& stackMark)
at System.Reflection.RuntimeMethodInfo.InternalInvoke(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, StackCrawlMark& stackMark)
at System.Reflection.MethodBase.Invoke(Object obj, Object[] parameters)
at System.Delegate.DynamicInvokeOne(Object[] args)
at System.MulticastDelegate.DynamicInvokeImpl(Object[] args)
at System.Delegate.DynamicInvoke(Object[] args)
at System.Windows.Threading.DispatcherOperation.Invoke()
at System.Windows.Threading.Dispatcher.Dispatch(DispatcherPriority priority)
at System.Windows.Threading.Dispatcher.OnInvoke(Object context)
at System.Windows.Hosting.CallbackCookie.Invoke(Object[] args)
at System.Windows.Hosting.DelegateWrapper.InternalInvoke(Object[] args)
at System.Windows.RuntimeHost.ManagedHost.InvokeDelegate(IntPtr pHandle, Int32 nParamCount, ScriptParam[] pParams, ScriptParam& pResult)


I checked the references and rechecked them multiple times – all assemblies referenced by the application project originally were referenced by the class library now, but this still didn’t wok. After a few hours of banging my head on the desk I binged some forum discussion that suggested having some assemblies referenced in both the application and a class library…

After I restored the references to Microsoft.Expression.Interactions and System.Windows.Interactivity to the application project – everything started working again… Success!

Normally in .NET when you have an assembly A that references assembly B that references assembly C – assembly A does not need to reference assembly C. It seems though that in my case – the XAML of a ResourceDictionary, with a Style/ControlTemplate was somehow parsed by the code in the application assembly (A) and it did not recognize the types defined in Blend assemblies (C). Back to dll hell…