Добрый день...
собственно вопрос в следующем: есть ли возможность запихнуть какойнить WPF UI...ну допустим DockPanel с размещённой на ней элементами в Add-in(System.Addin), чтобы потом Хост-приложение могло размещать эту докпанель на себе и чтобы эта докпанель была полноценным элементом хост-приложения...
читал мсдн...там описаны ограничения, которые не позволяют делать с UI расположенным в Addin некоторые вещи...например такие как трансформация...

так вот может у когонить удачно получалось с использованием System.Addin разносить элементы UI по разным сборкам?

=) судя по довольно маленькому количеству ответов, никто UI-parts приложения в System.Addin не запихивал...
в общем UI я туда запихнул...только когда я его дёргаю из плагина и располагаю на форме, он выглядит как обычный WinForms контрол...и никакие стили к нему почему-то не применяются...

мож кто знает как это обойти?

Partizan, не работал с аддинами. Вообще, пока что не очень хорошо понимаю что ты пытаешься сделать. что значит "запихнуть какойнить WPF UI"?

суть такова:
1)есть некоторое приложение-хост...оно представляет собой главную форму...
2)есть множество других приложений, которые оформлены как add-inы...каждое из этих приложений имеет UI(Grid с дочерними элементами), который при желании может дёргаться хостом для последующего расположения в некой области главной формы.

так как Хост и Add-in загружаются в разные домены, то дёргать UI из Add-inов приходится через методы FrameworkElementAdapters::ViewToContractAdapter и FrameworkElementAdapters::ContractToViewAdapter...таким образом UI пересекает границы домена в который загружен Addin  и попадает в домен Хоста. В результате получается экземнляр некоего класса обёртки MS.Internal.Control.AddInHost(фактически насколько я понимаю передаётся просто hwnd UIElement-а и располагается на главной форме так же как и обычный WinForms контрол) =(

в общем проблема со кастомным стайлингом UI-партов из addin-а решилась, но появилась другая:

надо чтобы UI выдернутый из add-inа наследовал стиль хост-окна...но и с этим я наверно справлюсь...
на днях отпишу что и как из этого получится...

всё получилось, всё отлично...
скажу лишь что задача реализуема ибо описать всё вкраце очень тяжело.
так что если у кого-то будут подобные проблемы, обращайтесь =)

sample дай) интересно ж...

Всё будет =) только попозже чуть) на выходных не было времени писать статью)

sample очень уж хочется увидеть) 
могу выложить свой пример - если есть время, хотелось бы услышать совет (как в приложение с docking-панелью встроить addin с другим winforms контролом)
не смог (пока) решить проблему с эксепшеном в PresentationFramework, возникающим при перемещении docking-панели и некорректным отображением контрола (не растягивается внутри контейнера в отличии от контролов, создаваемых в том же домене)

спасибо

Для plug-in'ов есть специально обученный framework - MAF Manager AddIn Framework with WPF

xxxSeVa, MAF == System.Addin....в топике о нём и речь...


lehin, руки пока дошли написать только одну статью о System.Addin...на подходе вторая...
но взаимодействие с UI-ными элементами из других доменов будет где-то в 3-й или 4-й статьях, которые, скорее всего будут в начале мая...

Последняя тенденция - ругать System.AddIn, хвалить MEF.

Partizan, может, ну его этот System.AddId? ;)

Idsa, нет-нет ) Это взаимодополняющие технологии..Основная фича System.Addin - изоляция плагинов... MEF обеспечивает другие вещи, очень, кстати сладкие, но не обеспечивает того, что даёт System.Addin 

Да, MEF совсем из другой серии.А зачем вам нужна эта изоляция в купе с дополнительными тормозами?Простой загрузки модулей по требонию не достаточно?Трудно представить вариант,где выгрузка критична.

xxxSeVa, 

если я разработчик некоего программного комплекса и у моего комплекса есть некоторый Public API, а я не хочу, чтобы бажные плагины сторонних разработчиков отваливали моё приложение, то использование изоляции было бы полезно

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

спасибо за ссылку

Жаль, конечно, что для встраивания объектов интерфейса из addin'а в основное приложение приходится использовать wpf - много памяти кушается, что называется, просто так. 
В принципе на данный момент я реализовал то, что хотел - прототип системы с подключаемыми модулями, логика работы которых изолирована. Из статьи еще раз убедился, что этот вариант архитектуры на данный момент единственно возможный.