Какие проблемы возникают при запуске WPF на нескольких доменах приложений в одном потоке пользовательского интерфейса? - PullRequest
Новая
       52

Какие проблемы возникают при запуске WPF на нескольких доменах приложений в одном потоке пользовательского интерфейса?

4 голосов
/ 24 февраля 2009

Мы смотрим на создание пользовательского интерфейса WPF, который работает на нескольких доменах приложений. Один из доменов приложения будет запускать приложение, в то время как остальные домены приложения будут содержать ряд пользовательских элементов управления и логики. Идея, конечно же, заключается в том, чтобы изолировать эти пользовательские элементы управления и логику от основного приложения.

Здесь - это пример использования MAF / System.AddIn. Какой опыт другие испытали с этим? Как это решение обрабатывает RoutedEvents / Commands, которые могут возникать внутри одного пользовательского элемента управления, и правильно ли они сериализуются в доменах приложений? А как насчет ресурсов WPF? Можно ли легко получить доступ к ним через домены приложений?

Ответы [ 2 ]

2 голосов
/ 16 апреля 2013

Старый вопрос, но тем не менее: вам нужно будет иметь несколько потоков пользовательского интерфейса - по одному на домен приложения. Создайте их так: 

        var thread = new Thread(() =>
        {
            var app = new Application();
            app.Run();
        });
        thread.Name = AppDomain.CurrentDomain.FriendlyName;
        thread.SetApartmentState(ApartmentState.STA);
        thread.Start();

Самой большой проблемой является то, что вы не можете отправлять FrameworkElements между доменами приложений (они не являются MarshalByRefObject), но вы можете использовать методы FrameworkElementAdapters.ViewToContractAdapter () и ContractAdapterToView (), чтобы обойти это ограничение. Подробнее см. На странице FrameworkElementAdapters MSDN.

Затем, как только вы это сделаете, самая большая проблема IMHO состоит в том, что вы не можете ничего положить поверх FrameworkElement из «удаленного» домена (классическая «проблема воздушного пространства»). См. эту тему для получения дополнительной информации об этом.

0 голосов
/ 29 мая 2009

Я ответил на симуляционный вопрос здесь и отредактировал его также для WPF. Вы можете использовать интересное свойство того, как работает движок компоновки, чтобы покрыть диспетчерский насос в одном из контекстов рендеринга. Это действительно легкий вариант.

Кроме того, я полагаю, вы знаете о корпоративной библиотеке и unity ?

Существует блок приложения WPF , поэтому использование этого шаблона не является слишком болезненным;) Но разве они не говорят, без боли нет выгоды?

Существует также CAB (составной блок приложения пользовательского интерфейса), связанный в единство. WPF SDK разработчики создали платформу Silverlight & WPF. (a.k.a Prism).

О, верно, вы также спрашивали о Ресурсах? Я предпочитаю загружать ресурсы вручную в классе Application. Я понял одну вещь: скажем, у вас есть ResourceDictionary в подпапке, и вы загружаете MergedDictionaries в этот ResourceDictionary. Итак, если в вашем классе Application вы загружаете «my-res-dir / MergedDictionaryLoader.xaml» (по коду или xaml), ВСЕ БУДУЩИЕ ЗАГРУЗКИ MERGEDDICTIONARIES ЗАГРУЖАЮТСЯ ИЗ «my-res-dir».

В некотором роде безумие, если вы спросите меня, я думаю, что поскольку текущий каталог процесса не изменился, вы должны указать «my-res-dir / foo.xaml» для всех ваших дополнительных каталогов. Однако это не так (я не верю, что это где-то задокументировано, по крайней мере, очень хорошо и должно рассматриваться как ошибка imho).

Помните, что загрузка словаря ресурсов WPF будет основываться на каталоге, из которого находится текущий XAML . Таким образом, вы указываете Source = "foo.xaml" изнутри вашего "my-res" -dir / MergedDictionaryLoader.xaml». Я даже играл с пакетом URI / абсолютным синтаксисом, однако никогда не находил, что это слишком интуитивно.

...