BackgroundWorker y WebBrowser Control

Question

¿Es posible/recomendable utilizar subprocesos de trabajo en segundo plano con el control del navegador web?

Estoy creando un bot que busca palabras clave en google, luego busca sitios en las primeras 10 páginas para ver si un sitio está clasificado.

El usuario puede proporcionar un máximo de 20 sitios para verificar y puede usar proxies. Entonces, idealmente, me gustaría tener 5 hilos trabajando a la vez.

¿Es posible? Podría haber escuchado en alguna parte que hay problemas con el control y los hilos de WebBrowser.

Answer 1

No lo es. WebBrowser utiliza Internet Explorer, que es un componente COM. Los componentes COM tienen un modelo de subprocesamiento, IE usa "Apartamento". Que es una palabra cara que significa que no es seguro para subprocesos. Puede llamar a sus métodos en un BGW pero COM asignará automáticamente la llamada a la secuencia de la interfaz de usuario. Dado que todas las llamadas a métodos y los accesos a propiedades realmente suceden en el subproceso UI, lo hará más lento utilizando un BGW.

De hecho, puede ejecutar WebBrowser en otro hilo, tendrá que crear una instancia del mismo en ese hilo. Y tendrá que crear un hilo que sea un llamado Single Threaded Apartment. STA, un acrónimo que bien podría reconocerse desde el atributo [STAThread] en el método Main() de una aplicación Winforms o WPF. Cambiar un hilo de trabajo a STA requiere llamar a Thread.SetApartmentState() antes de iniciarlo. No puedes hacer esto por un BGW. Y el hilo debe bombear un bucle de mensaje para implementar el contrato de STA, debe llamar a Application.Run(). Obligatorio, por lo menos, para que WebBrowser eleve sus eventos. This answer muestra el enfoque.

Considere usar la clase WebRequest.

Answer 2

¿Hay algún motivo por el que esté utilizando el control IE sobre una biblioteca como HTML Agility pack? Eso tiene soporte multihilo sin la pesadilla COM de IE, y es mucho más poderoso con el análisis de HTML.

Answer 3

Para responder a su pregunta inmediata: Nunca lo he intentado, pero no me sorprendería si hubiera problemas. Los controles WinForms en general no están destinados a ser accedidos desde hilos que no sean el hilo principal de UI. Debe usar el método Control.Invoke() para ejecutar métodos de invocación desde otros subprocesos. Esto los pone en cola en el hilo principal de UI.

Para resolver el problema más amplio: probablemente sea mejor que no uses un control WebBrowser si no necesitas renderizar HTML para que el usuario lo vea. Puede descargar una página usando la clase HttpWebRequest, que es mucho más liviana. WebBrowser es básicamente Internet Explorer completo integrado en su aplicación.