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

Question

Есть ли способ использовать C # для создания контейнерного приложения, где каждая вкладка на самом деле представляет собой собственный процесс, как в Google Chrome?

Answer 1

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

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

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

Answer 2

Для тех из вас, кто заинтересован в реальной реализации многопроцессорных приложений, я написал об этом статью на своем веб-сайте: Многопроцессное приложение на C #, например, Google Chrome .

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

Именованные каналы: как процессы общаются друг с другом

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

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

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

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

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

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

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

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

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

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

Answer 3

Отметьте этот пост в блоге Chromium. Только один процесс отвечает за фактическое отображение на экране.

Answer 4

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

Answer 5

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

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

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

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

Answer 6

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

Answer 7

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

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