Finding Globalized Resource files when remotely loading an assembly

Question

Our code uses a "Plugin" model, that remotely loads dll's conforming to a predefined structure IPluginModel that is defined in the main program. The main program itself has several localized forms where the text and placement of the labels in the UI are all changed based on the different localization Thread.CurrentThread.CurrentUICulture.

One thing that we noticed is that any forms or reports from the remotely loaded dll's will never be properly localized. It does not seem to matter where the localization dll's containing the different resources for the plugin are located, either next to the main form, next to the plugin dll, or anywhere else. How would one cause the Assembly to correctly locate its localized resources when the assembly itself is loaded during RunTime of the main program?

I do have code that rather resembles the method used Here, but dont want to have to manually implement the resx against the form itself if at all possible. The code I have is located directly inside the plugin itself and is called whenever the CurrentUICulture is NOT "en-US".

Ideally speaking, what Im looking for is a way to load the pluginName.resources.dll which is directly associated with the plugin I just loaded. I do see the different folders in my main projects bin folder, the es folder contains a main.resources.dll, but simply placing the plugin dll's in that folder did not seem to work last time I tried it, although in theory that could have changed...or I may have done it wrong at the time...

Loading the assembly [code snippet]

    private void LoadPlugin(string filePath)
    {
        bool isValidPlugin = false;
        Assembly asm = null;
        try
        {
            asm = Assembly.LoadFrom(Path.Combine(Environment.CurrentDirectory, filePath));
                //Do some type checking to make certain this is in fact one of OUR plugins
            var p = (IFTLPlugin)Activator.CreateInstance(types[x]);
                _plugins.Add(p.Prefix, p);
            }
        }

Edit: More thoughts on the subject

Is there some way to intercept the loading structure that attempts to resolve the satellite assemblies, an event that I can implement or a function I can override, where I can manually point the code to the correct resource assembly?. I found some things about assembly resolution, but that was for direct loading, not for satellite resources.

Answer 1

As you know perfectly well already, the runtime loads localized resources using a convention, by looking for satellite assemblies (e.g. fr/pluginName.resources.dll).

I think you may be right to think that this issue may be due to a failure to find those satellite assemblies . You could try confirming this using the .NET Framework diagnostics tool fuslogvw.exe. You can also try to deploy your satellite assemblies to the Global Assembly Cache (GAC) as a quick fix (see Installing a Satellite Assembly in the Global Assembly Cache on this page).

If that works, and to help figure out other suitable locations (other than the GAC), the locations inspected by the runtime to look for satellite assemblies are documented as the fallback process here: http://msdn.microsoft.com/en-us/library/sb6a8618%28v=vs.71%29.aspx