Hay esos [MTAThread] y [STAThread] que controlan el modelo de subprocesos de apartamento para COM en aplicaciones .Net, y desde mi propia prueba (muy limitada), CoInitializeEx() devuelve 1 ( S_FALSE ) si se llama desde el subproceso principal de un aplicación de consola C#.
Según la documentación de Microsoft, S_FALSE significa "La biblioteca COM ya está inicializada en este subproceso".
Lo que me pregunto es si realmente existe una garantía contractual en el propio marco de que COM se inicializará en cada subproceso .Net (Framework o Core application).
Si es así, ¿también se garantiza que todos los subprocesos se inicializarán con el mismo modelo (STA o MTA)?
Lo pregunto porque para las aplicaciones de DirectShow es crucial que COM se inicialice en cada subproceso, y me gustaría evitar salpicar el código con llamadas redundantes a CoInitializeEx() y CoUnitialize() si el marco ya las maneja implícitamente.
La documentación establece que los subprocesos del grupo de subprocesos administrados son
en el apartamento multiproceso
La documentación de Task.Run() también establece que
Pone en cola el trabajo especificado para que se ejecute en ThreadPool
( ThreadPool en este caso es el grupo de subprocesos administrado).
Finalmente, la documentación para la propiedad obsoleta ApartmentState de la clase Thread establece que
En la versión 2.0 de .NET Framework, los subprocesos nuevos se inicializan como ApartmentState.MTA si su estado de apartamento no se ha establecido antes de que se inicien.
Eso cubre prácticamente todas las formas administradas de crear un hilo.
Por supuesto, también podría colocar un atributo [MTAThread] en su método Main() , pero incluso eso no es necesario porque el valor predeterminado para el punto de entrada principal también es MTA.
Entonces, al final del día, a menos que esté llamando a un código de terceros inusual, puede estar casi seguro de que sus subprocesos serán MTA.