1
votes

My application has an interface IProgressUIPlugin defined in project ProjectNameLib, and the interface is implemented in another DLL. My main application directly references ProjectNameLib and loads the interface implementation's assembly from the /plugins/ folder when it starts up. The interfaces have been copy and pasted, with comments and redundant methods stripped, below:

public interface IProgressUIPlugin : IApplicationNameExtension
{
   IProgressUIWindow CreateNew();
}

public interface IProgressUIWindow : IDisposable
{
   void Close();
   void Update(string title, string subtitle, string status, double progress);
}

The interface implementation is implemented in two pieces:

  1. ProjectName.Plugins.BasicProgressUI - implements IProgressUIPlugin, IProgressUIWindow
  2. ProjectName.Plugins.BasicProgressUI.Blend - Actual WPF view and viewmodel

The DLL implementing the interface is properly loaded so that I am able to invoke the method pluginInstance.CreateNew(). However, my assembly resolver then tries to resolve.

ProjectName.Plugins.BasicProgressUI.Blend.resources, Version=1.0.0.0, Culture=en-US, PublicKeyToken=null
ProjectName.Plugins.BasicProgressUI.Blend.resources, Version=1.0.0.0, Culture=en-US, PublicKeyToken=null
ProjectName.Plugins.BasicProgressUI.Blend.resources, Version=1.0.0.0, Culture=en, PublicKeyToken=null
ProjectName.Plugins.BasicProgressUI.Blend.resources, Version=1.0.0.0, Culture=en, PublicKeyToken=null

Both resolutions fail (my AssemblyResolve event handler searches for the plugin directory, but nothing of that name exists) and my window displays without the styling specified within its resource dictionary.

Stuff I've tried so far:

  1. Fiddling around with [assembly: NeutralResourcesLanguageAttribute("en-US", UltimateResourceFallbackLocation.MainAssembly)]. Tried using Satellite, MainAssembly, and not having the Attribute specified. Satellite causes a throw after the assemblyresolve invocations, MainAssembly causes AssemblyResolve to not be invoked, and not specifying it causes AssemblyResolve to be invoked.
  2. Explicitly returning the WPF Project assembly when assemblyresolve is asked to resolve the .resources file.
  3. Lots of googling (queries such as "wpf resources assemblyresolve", "assemblyresolve resourcedictionary", etc).

I'm aware that for this case, I could just hard-code the color values into the WPF Window to fix the problem, but in the future, we'll be having various resources, localization, skinning, etc, so I figured I should just solve the problem now.

I've described the problem as best as I can. If you have any questions, I'll definitely respond.

Thanks!

Links:
The plugin implementation can be found here at code.google.com/the-dargon-project/
The addin manager/assembly resolver can be found here at code.google.com/the-dargon-project/

1

1 Answers

0
votes

A WPF-experienced person in my project went through my code and it turned out that I was loading the resourcedictionary in App.xaml (which seems to be like an entry point for WPF applications). However, that entry point isn't called when you load a WPF project as a plugin and instantiate one of its classes (which makes a lot of sense), so the resource dictionary wasn't being loaded. He solved the problem by moving

<ResourceDictionary>
   <ResourceDictionary.MergedDictionaries>
      <ResourceDictionary Source="Simple Styles.xaml"/>
   </ResourceDictionary.MergedDictionaries>
</ResourceDictionary>

from App.xaml to BasicProgressUIWindow.xaml.cs

The window now properly loads its style configuration resources. However, the failed assembly resolves still occur, and we're trying to figure out what they're supposed to mean.