Приложение Windows Forms, такое как Google Chrome с несколькими процессами

Ответ 1

Вы можете использовать SetParent вызов Win32 для этого, но это действительно чревато проблемами. У меня было достаточно проблем, чтобы все было хорошо работать с окнами из разных приложений AppDomains - было бы еще больше проблем со всеми дополнительными процессами.

В принципе, между двумя процессами требуется много коммуникации - такие вещи, как изменение размера, могут стать довольно болезненными, а также то, что произойдет, если дочернее приложение захочет выйти и т.д. Все это выполнимо, но я бы очень тщательно подумал Делать это. Для браузера это имеет большой смысл (отказ от ответственности: я работаю в Google), но для большинства других приложений это действительно не стоит усилий.

(Являются ли "вкладки" для создания реальных приложений .NET? Если это так, как я уже сказал, это становится значительно проще - и я могу дать вам большой совет, который заключается в том, что каждый пользовательский интерфейс должен запускать собственный поток пользовательского интерфейса изнутри его собственный AppDomain. Вы получаете действительно странные эффекты, если вы этого не делаете!)

Ответ 2

Для тех из вас, кто интересуется фактической реализацией приложений с несколькими процессами, я написал статью об этом на своем веб-сайте: Multi-process С# как Google Chrome.

Я включил рабочий код С#. Он был протестирован для работы с .NET 2.0,.NET 3.0 и .NET 3.5.

Именованные каналы: как процессы взаимодействуют друг с другом

Поскольку ваш вопрос специально спросил о Google Chrome, вы должны знать, что Chrome использует именованные каналы для связи между процессами.

В исходном коде С#, упомянутом выше, есть 2 файла: PipeServer.cs и PipeClient.cs. Эти 2 файла представляют собой тонкие оболочки API-интерфейсов Named Pipes. Он хорошо протестирован, потому что сотни тысяч людей используют наши продукты. Поэтому требовалась стабильность и надежность.

Как мы используем дизайн с несколькими процессами

Теперь, когда у вас есть все части головоломки, позвольте мне рассказать вам, как мы используем Multi-process design в нашем приложении.

Наш продукт представляет собой полное обновление. То есть существует программа которая строит обновления патчей (не относится к обсуждению), автономная программа обновления (wyUpdate - также с открытым исходным кодом) и Автоматический контроль обновлений, который наши пользователи накладывают на свои С# или Формы VB.NET.

Мы используем именованные каналы для связи между автономным обновлением (wyUpdate) и синтаксисом автоматического обновления, который находится в вашей программе. wyUpdate сообщает о прогрессе в автоматическом обновлении, и Automatic Updater может сообщить wyUpdate об отмене прогресса, начать загрузку, начать извлечение и т.д.

Фактически, точный код именованных каналов, который мы используем, включен в статью, упомянутую выше: Многопроцессорное приложение С#, такое как Google Chrome.

Почему вы не должны использовать многопроцессорный дизайн

Как упоминал выше Джон Скит, у вас должна быть конкретная потребность в многопроцессной модели. В нашем случае мы хотели, чтобы программа обновления полностью отделилась от вашей программы. Таким образом, если программа обновления как-то рухнула, ваша программа останется невредимой. Мы также не хотели дублировать наш код в двух местах.

Если сказать, что даже с нашей проверенной оболочкой Named Pipes, межпроцессная связь сложна. Поэтому осторожно пройдитесь.

Ответ 3

Отметьте этот пост в блоге Chromium. Фактический рендеринг на экран отвечает только один процесс.

Ответ 4

API System.AddIn, представленный в .NET 3.5, позволяет использовать элементы управления пользовательским интерфейсом в отдельном AppDomains. С некоторыми прыжками с обручем вы можете заставить его работать и в отдельных процессах.

Это поддерживается navtively в WPF. См. Образец MSDN Надстройка возвращает пользовательский интерфейс.

Используя Windows Forms, это выглядит не так, как это возможно с помощью API System.AddIn. См. этот пост от архитектора System.AddIn Джека Гуденкауфа.

Однако для WinForms существует обходной путь. Вы можете сделать эту работу небольшим взломом: см. Блог команды BCL Поддержка форм Windows в System.AddIn Хосты и надстройки

Ответ 5

Мой продукт, WindowTabs.com, это как-то. Вам нужно использовать Win32 - я предлагаю вам избегать использования SetParent, потому что вы завершаете добавление потока. Вместо этого нарисуйте вкладки над окнами и используйте SetWindowPos для перемещения окон в виде группы. Кроме того, некоторые сторонние элементы управления, такие как Infragistic, не работают правильно, если вы родили форму на уровне Win32.

Ответ 6

Да. Вы можете создавать новые процессы с помощью System.Diagnostics.Process. Используя некоторую форму межпроцессное общение (IPC), .NET Например, удаляя, вы можете общаться между процессами. И затем вы можете установить родительский элемент окна/формы вашего нового процесса в окно (вкладку) вашего первого процесса, чтобы оно появилось там.

Ответ 7

Не глядя слишком глубоко в стек расширяемости, вы можете использовать пространство имен System.Addin для создания приложения, которое по своей сути может создавать аддины как визуальные отдельные вкладки и установить каждую вкладку/добавление в качестве процесса вывода, и это поведение из коробки.

Он будет иметь те же функции, что и хромированные вкладки.