Google Chrome und IE8 (unter anderem) zielen darauf ab, größere Zuverlässigkeit/Stabilität zu bieten, indem jede Registerkarte (Webseite) in einem separaten Prozess isoliert wird (zu vereinfacht, ich weiß).Chrome/IE8 Multi-Prozess-Design, ist es in .NET möglich?
Dies scheint viel mehr Schwergewicht als mehrere Threads zu sein, aber hat den großen Vorteil eines Absturzes in einem Prozess nicht die gesamte Anwendung zu bringen.
Es scheint, dass die multiple Prozessarchitektur lange in serverseitigen Anwendungen (z. B. Webservern) verwendet wurde, aber dies sind Prozesse ohne dedizierte GUI. Es ist interessant, dass es jetzt in den Benutzerschnittstellen von Desktop-Anwendungen verwendet wird.
Wie würde ich das in einer Windows Forms .NET-Anwendung implementieren? Ist es überhaupt möglich?
Process.Start() ist ein offensichtlicher erster Ort, aber die GUI des neuen Prozesses ist nicht eng mit der GUI der Host-Anwendung integriert. Es handelt sich um eine neue eigenständige Anwendung, nicht um eine Untersteuerung/ein Fenster der Hostanwendung wie bei Chrome/IE8.
(Für interessierten jedermann Scott Hanselmann ein gutes Intro schrieb an die IE8 multi-process architecture here..)
[Update]
Genauer gesagt:
Wie kann ein separater "Unterprozess" macht direkt an die UI im "Hauptprozess"? Ist dies tatsächlich der Fall oder wird in Kommentaren vorgeschlagen, verwendet der Unterprozess IPC, um den Hauptprozess danach zu fragen?
+1, vor allem die Einschränkungen der Kommunikation zwischen den Domänen. Das kann viel teurer sein, als Entwickler manchmal erwarten. –
Können 2 AppDomains in einem einzigen Prozess die Benutzeroberfläche unabhängig voneinander aktualisieren, dh separate Tabs? Auch, wie Scott Hanselmann sagt, ist es immer noch möglich, den gesamten Prozess von einer AppDomain herunter zu bringen. – Ash
@Ash unter Annahme eines Prozesses/AppDomain ist der "GUI" -Prozess, der dafür verantwortlich ist, Befehle von anderen Prozessen zu empfangen und diese zu reflektieren; und zurück zu ihnen, warum nicht? –