none
XAML references not resolved via "myassembly.GetReferencedAssemblies()" RRS feed

  • Question

  • I have a WPF container application (with ContentControl host) and a containee application (UserControl). Both are oblivious of each other.

    Only one XML config file holds the string dllpath of the containee's DLL and full namespace name of the ViewModelClass inside the containee.

    A generic code in container resolves containee's assembly (Assembly.LoadFrom(dllpath)) and creates the viewmodel's instance using Activator.CreateInstance(vmType). When this viewmodel instance is hosted inside the ContentControl of the container, and relevant viewmodel specific ResourceDictionary is added to ContentControl.Resources.MergedDictionaries in the container, the view loads fine.

    Requirement:

    Now my containee has to host the WPF DataGrid using assembly reference of WPFToolkit.dll from my local C:\Lib folder.

    The Copy Local reference to the WPFToolkit.dll is added to the .csproj file of the containee's project and its only referred in the UserControl.XAML using its XAML namepsace. This way my bin\debug folder in my containee application, gets the WPFToolkit.dll copied.

    XAML:

    xmlns:Controls="clr-namespace:Microsoft.Windows.Controls;assembly=WPFToolkit" <Controls:DataGrid ItemsSource="{Binding AssetList}" ... />

    Issue: The moment the ViewModel (i.e. the containee's usercontrol) tries to load itself I get this error.

    "Cannot find type 'Microsoft.Windows.Controls.DataGrid'. The assembly used when compiling might be different than that used when loading and the type is missing."

    Hence I tried to load the referenced assemblies of the containee's assembly (myAssembly.GetReferencedAssemblies()) before the viewmodel is hosted. But WPFToolkit isnt there in that list of assemblies!

    Strange thing is I have another dll referred called Logger.dll in the containee codebase but this one is implemented using C# code behind. So I get its reference correctly resolved in myAssembly.GetReferencedAssemblies().

    So does that mean BAML references of assemblies are never resolvable by GetReferencedAssemblies?

    EDIT:

    Forgot to add that I did post build event in containee's project to xcopy too 'bin\debug' contents to the 'bin\debug' of container. And it works then.

    But I dont want all containees (probably hundreds ot them in future) to be copied like this into container's debug folder.

    • Edited by Vinit Sankhe Monday, October 15, 2012 9:50 AM
    • Moved by Sheldon _Xiao Tuesday, October 16, 2012 4:48 AM (From:Windows Presentation Foundation (WPF))
    Monday, October 15, 2012 9:44 AM

Answers

  • Hi Vinit,

    Welcome to the MSDN Forum.

    If you don't want to always copy the reference to the application folder, you can try to install the reference in GAC: http://msdn.microsoft.com/en-us/library/dkkx7f79.aspx And the Gacutil.exe is helpful: http://msdn.microsoft.com/en-us/library/ex0ss12c.aspx  

    Here is the CLR locate the assembly: http://msdn.microsoft.com/en-us/library/aa720133.aspx 

    The runtime uses the following steps to resolve an assembly reference:

      • Determines the correct assembly version by examining applicable configuration files, including the application configuration file, publisher policy file, and machine configuration file. If the configuration file is located on a remote machine, the runtime must locate and download the application configuration file first.
      • Checks whether the assembly name has been bound to before and, if so, uses the previously loaded assembly.
      • Checks the global assembly cache. If the assembly is found there, the runtime uses this assembly.
      • Probes for the assembly using the following steps:
        1. If configuration and publisher policy do not affect the original reference and if the bind request was created using the Assembly.LoadFrom method, the runtime checks for location hints.
        2. If a codebase is found in the configuration files, the runtime checks only this location. If this probe fails, the runtime determines that the binding request failed and no other probing occurs.
        3. Probes for the assembly using the heuristics described in the probing section. If the assembly is not found after probing, the runtime requests the Windows Installer to provide the assembly. This acts as an install-on-demand feature.

    This is why you need to copy them to the application folder.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Tuesday, October 16, 2012 8:20 AM
    Moderator