6

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.

4

2 回答 2

2

正如您已经非常清楚的那样，运行时通过查找附属程序集（例如fr/pluginName.resources.dll）使用约定加载本地化资源。

我认为您认为这个问题可能是由于未能找到这些附属程序集可能是正确的。您可以尝试使用 .NET Framework 诊断工具fuslogvw.exe确认这一点。您还可以尝试将附属程序集部署到全局程序集缓存 (GAC) 作为快速修复（请参阅本页在全局程序集缓存中安装附属程序集）。

如果这可行，并且为了帮助找出其他合适的位置（GAC 除外），运行时检查以查找附属程序集的位置在此处记录为后备过程：http: //msdn.microsoft.com/en-我们/图书馆/sb6a8618%28v=vs.71%29.aspx

于 2012-11-07T10:57:09.513 回答
0

正如您在问题背景中指出的那样，.NET 系统在加载资源程序集时使用Thread.CurrentThread.CurrentUICulture 。

问题是每个新线程都默认为CultureInfo.InstalledCulture，除非另有说明。

让您的主代码在初始化调用中将所需的文化传递给库。

然后在加载任何资源之前让库设置它的Thread.CurrentThread.CurrentUICulture（和.CurrentCulture ，如果合适的话）。例如，这将是在调用InitializeComponent()或TryFindResource()之前。

这使库的线程文化与主程序的线程文化保持一致，而不管操作系统对此的想法是什么。

于 2012-11-07T05:13:05.070 回答