locked
Assembly load failure in WPF ToolWindow RRS feed

  • Question

  • Hi,
     
    I'm building a really simple extension composed of WPF ToolWindow (a
    User Control) every thing is working fine execpt that I cannot use some
    feature (such as attached properties or custom markup extentions) from
    a third party library.
     
    I've referenced the library, correctly digitally signed, and if I use
    types defined in the library within my code everything is working fine
    but if I reference an xml namespace in my user control xaml such as:
     
     
    <ListView behaviors:ListViewManager.ItemDoubleClickCommand="{Binding
    Path=MyCommand}"
             ItemsSource="{Binding Path=Workspaces}"
             DisplayMemberPath="Name" />
     
    the third party assembly fails to load with a FileNotFoundException, it
    is not a type load exception so there are no loader exceptions. The
    only thing I can say, about the third party library, is that is is
    built against fx 3.5 not 4.0.
     
    Any idea?
     
    .m
     

    Mauro Servienti
    {C67C0157-5D98-4733-A75E-93CAEE4BADC8}
    Microsoft MVP - Visual C# / MCTS
    http://mvp.support.microsoft.com
    blog @ http://milestone.topics.it
    whynot [ at ] topics [ dot ] it
    Tuesday, May 3, 2011 7:47 AM

Answers

  • Hi Ryan,

    You wrote on 03/05/2011 :

    xmlns:behaviors="http://schemas.topics.it/wpf/radical/windows/behaviors"

    Have you tried using the namespace format which uses the actual namespace name + assembly name.  I am not overly familar with the 'mapping' above and how it works, but it may be that WPF is having problems in a reflection load context with mapping from the random 'schema' path to the assembly/namespace.

    solved: the problem was that one of the type of the third party library dynamically loads the log4net dll that was missing, since the load was dynamic (without a static reference) the compiler can not detect the dependency and I was getting a runtime exception.

    Ryan

    Thanks for your support.

    .m


    Mauro Servienti
    {C67C0157-5D98-4733-A75E-93CAEE4BADC8}
    Microsoft MVP - Visual C# / MCTS
    http://mvp.support.microsoft.com
    blog @ http://milestone.topics.it
    whynot [ at ] topics [ dot ] it
    Wednesday, May 4, 2011 5:21 AM

All replies

  • Where is the assembly located at runtime? Is it GACed or side by side with your extension assembly? Have you run fuslogvw to see where the runtime is looking for thw assembly?

    Ryan

    Tuesday, May 3, 2011 1:55 PM
  • Hi Ryan,
     
    thanks for the response, the assembly is in the vsix package. As I said
    before the interesting thing is that using types of that specific
    assembly from the UserControl code-behind wqorks perfectly.
     
    Il "attach" fuslog and post the result here.
     
    .m
     

    Mauro Servienti
    {C67C0157-5D98-4733-A75E-93CAEE4BADC8}
    Microsoft MVP - Visual C# / MCTS
    http://mvp.support.microsoft.com
    blog @ http://milestone.topics.it
    whynot [ at ] topics [ dot ] it
    Tuesday, May 3, 2011 2:11 PM
  • do not ask why but attaching "fuslogvw" makes everything works as
    expected :-) fear of the dark :-P
     
    Thanks,
    .m
     

    Mauro Servienti
    {C67C0157-5D98-4733-A75E-93CAEE4BADC8}
    Microsoft MVP - Visual C# / MCTS
    http://mvp.support.microsoft.com
    blog @ http://milestone.topics.it
    whynot [ at ] topics [ dot ] it
    Tuesday, May 3, 2011 2:17 PM
  • >xmlns:behaviors="http://schemas.topics.it/wpf/radical/windows/behaviors"

    Have you tried using the namespace format which uses the actual namespace name + assembly name.  I am not overly familar with the 'mapping' above and how it works, but it may be that WPF is having problems in a reflection load context with mapping from the random 'schema' path to the assembly/namespace.

    Ryan

    Tuesday, May 3, 2011 4:51 PM
  • Hi Ryan,

    You wrote on 03/05/2011 :

    xmlns:behaviors="http://schemas.topics.it/wpf/radical/windows/behaviors"

    Have you tried using the namespace format which uses the actual namespace name + assembly name.  I am not overly familar with the 'mapping' above and how it works, but it may be that WPF is having problems in a reflection load context with mapping from the random 'schema' path to the assembly/namespace.

    solved: the problem was that one of the type of the third party library dynamically loads the log4net dll that was missing, since the load was dynamic (without a static reference) the compiler can not detect the dependency and I was getting a runtime exception.

    Ryan

    Thanks for your support.

    .m


    Mauro Servienti
    {C67C0157-5D98-4733-A75E-93CAEE4BADC8}
    Microsoft MVP - Visual C# / MCTS
    http://mvp.support.microsoft.com
    blog @ http://milestone.topics.it
    whynot [ at ] topics [ dot ] it
    Wednesday, May 4, 2011 5:21 AM