Это своего рода продолжение одной из моих предыдущих статей, посвященной разрешению модулей в моем приложении WPF. Этот вопрос конкретно связан с влиянием взаимозависимостей модулей и метода построения этих модулей (т. е. через MEF или через new) на способность MEF разрешать отношения.
Я пробовал два подхода:
- левый подход: приложение реализует IError
- правильный подход: в приложении есть член, который реализует IError
Левый подход
Мой код выглядел так (только материал, связанный с MEF):
// app.cs
[Export(typeof(IError))]
public partial class Window1 : Window, IError
{
[Import]
public CandyCo.Shared.LibraryInterfaces.IPlugin Plugin { get; set; }
[Import]
public CandyCo.Shared.LibraryInterfaces.ICandySettings Settings { get; set; }
private ICandySettings Settings;
public Window1()
{
// I create the preferences here with new, instead of using MEF. I wonder
// if that's my whole problem? If I use MEF, and want to have parameters
// going to the constructor, then do I have to [Export] a POCO (i.e. string)?
Settings = new CandySettings( "Settings", @"c:\settings.xml");
var catalog = new DirectoryCatalog( ".");
var container = new CompositionContainer( catalog);
try {
container.ComposeParts( this);
} catch( CompositionException ex) {
foreach( CompositionError e in ex.Errors) {
string description = e.Description;
string details = e.Exception.Message;
}
throw;
}
}
}
// plugin.cs
[Export(typeof(IPlugin))]
public class Plugin : IPlugin
{
[Import]
public CandyCo.Shared.LibraryInterfaces.ICandySettings CandySettings { get; set; }
[Import]
public CandyCo.Shared.LibraryInterfaces.IError ErrorInterface { get; set; }
[ImportingConstructor]
public Plugin( ICandySettings candy_settings, IError error_interface)
{
CandySettings = candy_settings;
ErrorInterface = error_interface;
}
}
// candysettings.cs
[Export(typeof(ICandySettings))]
public class CandySettings : ICandySettings
{
...
}
Правый подход
В основном то же, что и левосторонний подход, за исключением того, что я создал класс, наследуемый от IError, в той же сборке, что и Window1. Затем я использовал [Import], чтобы попытаться заставить MEF разрешить это для меня.
Может ли кто-нибудь объяснить, почему два способа, которыми я здесь подошел к MEF, ошибочны? Я так долго был в неведении, что вместо того, чтобы читать о MEF и пробовать разные предложения, я добавил MEF в свое решение и приступаю к коду. Часть, где это выглядит как сбой, это когда он вызывает partManager.GetSavedImport(). По какой-то причине importCache имеет значение null, чего я не понимаю. Вплоть до этого момента он просматривал часть (Window1) и пытался разрешить два импортированных интерфейса — IError и IPlugin. Я бы ожидал, что он введет код, который просматривает другие сборки в той же исполняемой папке, а затем проверит его на предмет экспорта, чтобы он знал, как разрешить импорт...
Я нашел ошибку в своем коде, и когда я ее исправил, исключение MEF изменилось и стало более полезным. Он ясно указал, что не может найти конструктор CandySettings по умолчанию! И копая дальше, я нашел хороший пост от Гленна Блока, в котором это обсуждается. Поэтому мне нужно закончить чтение и посмотреть, поможет ли его обходной путь или нет. Я все равно был бы признателен за дополнительные ответы, поскольку невозможно сказать, является ли обходной путь правильным или нет.
