Partizan, я не работал ни с System.AddIn, ни с MEF... но из твоих слов сделал вывод, что MEF загружает сборку в родительский домен, а System.AddIn - в свой собственный. Так ли это?

Idsa, System.Addin может загружать либо в родительский домен, либо в новый домен, либо в отдельный процесс

Partizan, а MEF?

Idsa, ну а MEF загружает в родительский 

А чем вызвано такое ограничение?


А чего еще не дает MEF по сравнению с System.AddIn?

Idsa, у MEF  задачи другие




MEF  просто другой =) Если не нужна изоляция расширения, то я бы, конечно, посоветовал использовать MEF...
Если изоляция, которую предоставляет System.Addin не нужна, то функционал вполне можно реализовать с использованием MEF 

все-таки позволю себе привести свой пример - может моя ошибка сразу будет заметна

есть у меня плагин:

    [AddIn("Visual plugin")]
    public class VisualPlugin1 : AddInView.VisualPlugin
    {
        private System.Windows.FrameworkElement _control;

        public override string Name
        {
            get { return "Visual plugin"; }
        }

        public override System.Windows.FrameworkElement GetControl()
        {
            _control = _control ?? new UserControl1();
            return _control;
        }
    }

есть у меня хост и в нем метод загрузки плагинов:

        public void LoadAddIns()
        {
            _plugins = new List<PluginBase>();

            String path = AppDomain.CurrentDomain.BaseDirectory;
            AddInStore.Rebuild(path);
            IList<AddInToken> visualTokens = AddInStore.FindAddIns(typeof(VisualPlugin), path);

            foreach (AddInToken token in visualTokens)
            {
                _plugins.Add(token.Activate<PluginBase>(AddInSecurityLevel.Host));
            }

            foreach (PluginBase plugin in _plugins)
            {
                VisualPlugin visualPlugin = plugin as VisualPlugin;

                SimpleForm simpleForm = new SimpleForm();
                simpleForm.SetChild(visualPlugin.GetControl());
                simpleForm.Show();
            }
        }

все необходимые промежуточные объекты (контракты, адаптеры и пр. - все что нужно для AddIn) на месте, плагин загружается
проблема в том, что на форме контрол выглядит очень убого - не растягивается (не занимает весь ElementHost), не наследует стили и т.д. UserControl1 представляет собой обертку над простым winforms контролом.
Если UserControl в том же домене - он естесственно занимает весь контейнер ElementHost.

Кстати пытался сделать свой addin для wpf-калькулятора (от команды разработчиков технологии addin) - тот же простейший контрол в их приложении выглядит опять-таки убого (теряет цвет при перерисовке, отсутствуют стили xp несмотря на вызов System.Windows.Forms.Application.EnableVisualStyles(); )

Может что-нибудь посоветуете? 
Спасибо!

lehin, у вас и хост, и плагин на Windows Forms?

да, оба на winforms
wpf мне нужен только для передачи между доменами
соответственно, как и в примере, передаю wpf-контрол через INativeHandleContract

правда, та же проблема у меня возникает и при создании плагина с родными wpf-контролами - они точно так же не растягиваются

в конечном счете мне хотелось бы в качестве контейнера использовать DockContent с ElementHost (в приведенном примере - обычная форма с заполняющим ElementHost). Переданные через границу доменов контролы при изменении положения DockContent-панели (при любом изменении расположения панели) приводят к исключению в PresentationFramework (при этом кстати сама панель остается жить, но внутрии нее содержимое исчезает). Соответственно, контролы, созданные в том же домене ведут себя абсолютно нормально (растягиваются на всю панель, не выдают исключение при перемещении панели, выглягят в том же стиле)

lehin, я думаю, что передачу между доменами можно как-нибудь осуществить и без оборачивания в FrameworkElement...если с обеих сторон WinForms, то нет смысла контролы оборачивать...потому что при использовании WPF System.Addin накладывает некоторые ограничения

http://msdn.microsoft.com/en-us/library/bb...odelLimitations

а разве есть что-то для передачи контролов между доменами? вариант с разделением на слои модель-вид-представление отпадает сразу
да и в принципе ограничения не настолько критичны в том случае, если основное приложение служит только для запуска addin-ов
если не сложно, может быть покажете пример winforms-хост - wpf-addin?

или пример wpf-хост - winforms-addin? 
на мсдн все примеры wpf-wpf. Когда меню в их addin-е контрол с чистого wpf на обертку winforms - опять те же грабли (после перерисовки контрол меняет цвет)

спасибо, кстати, за ссылку - посмотрел я примеры которые там приведены и попытался их в своем winforms приложении захостить. опять получил исключение (см. аттач)
но уже по крайней мере контрол из другого домена весь контейнер занимает)

Присоединённый файл ( Кол-во скачиваний: 6 )
 1.jpg 49,32 Kb

нашел некоторое решение своей проблемы - для объекта DockPanel (http://sourceforge.net/projects/dockpanelsuite/) изменил свойство DocumentStyle со стандартного DockingMdi на DockingWindow - теперь исключение не выдается. 
Осталась единственная проблема - смена цвета фона контрола при перерисовке.

lehin, совсем недавно наткнулся на статейку как раз о расширении WIndows Forms-приложения с помощью System.Addin

http://msdn.microsoft.com/ru-ru/magazine/cc700355.aspx