¿Qué diferencia tiene UseShellExecute?

Question

Estoy comenzando una pequeña aplicación de consola desde mi aplicación web de IIS. El código se inicia desde dentro de un grupo de aplicación utilizando un código como éste,

Process process = new Process(); 
ProcessStartInfo processStartInfo = new ProcessStartInfo(); 

processStartInfo.CreateNoWindow = true; 
processStartInfo.WindowStyle = ProcessWindowStyle.Hidden; 

// .. 

process.Start(); 

que utiliza para obtener un error de forma intermitente,

Win32Exception exception has occured Message: No such interface supported 
ErrorCode: 80004005 NativeErrorCode: 80004002 

he demostrado que cuando esto sucedió la aplicación de consola no comenzaría a las todas.

que añade al código por encima de este,

processStartInfo.UseShellExecute = false; 

Y el problema ha desaparecido (hasta el momento, los dedos cruzados). Entiendo que al hacer este cambio no es necesario ejecutar un contexto de escritorio válido, pero qué significa exactamente eso. Si eso significa que no podemos ejecutar el código anterior si no hay un escritorio (que se aplica a un grupo de aplicaciones IIS que se ejecuta con un usuario del sistema), ¿por qué solía ejecutarse en ocasiones en el pasado en lugar de fallar todo el tiempo?

¿Alguien tiene alguna idea de por qué esto marcaría la diferencia? ¿Qué significa que no admite interfaz en este contexto?

ACTUALIZACIÓN:

he tenido en cuenta todo lo que la gente ha dicho, y hecho más yo misma investigación. Entonces, para resumir si tiene UseShellExecute = true (que es el valor predeterminado), entonces se llamará a ShellExecuteEX en shell32.dll para ejecutar el proceso. Esto se hará realidad (copiado del System.dll usando ILSpy),

public bool ShellExecuteOnSTAThread() 
{ 
    if (Thread.CurrentThread.GetApartmentState() != ApartmentState.STA) 
    { 
     ThreadStart start = new ThreadStart(this.ShellExecuteFunction); 
     Thread thread = new Thread(start); 
     thread.SetApartmentState(ApartmentState.STA); 
     thread.Start(); 
     thread.Join(); 
    } 
    else 
    { 
     this.ShellExecuteFunction(); 
    } 
    return this._succeeded; 
} 

Si tiene UseShellExecute = false entonces se llamará a CreateProcess en kernel32.dll para iniciar el proceso.

Me preguntaba si hay un problema con el hecho de que el código ShellExecuteOnSTATread anterior está creando un nuevo hilo? ¿Podría el grupo de aplicaciones llegar a algún límite en el subproceso que indirectamente podría causar una excepción Win32Exception?

Answer 1

Este error puede ocurrir cuando ciertos objetos COM no están registrados, aunque es un misterio para mí por qué es intermitente.

Para ser justos, engendrar un ejecutable local desde IIS es algo bastante raro de hacer y en realidad puede causar un problema de seguridad, o al menos causar un problema con IIS si el comando falla por algún motivo y no lo hace t devolver el control al sistema.

En realidad, la mejor práctica para algo así es registrar la acción que necesita suceda dentro del registro, base de datos o algún tipo de archivo de configuración y hacer que su aplicación local se ejecute como una tarea programada o un servicio de Windows.

Como referencia, UseShellExec indica si el Kernel debe iniciar el exe directamente o si debe solicitarle al Explorer que lance el archivo.

Es posible que aparezca este problema cuando no haya nadie conectado, por lo que no es necesario cargar el shell para ejecutar el archivo ejecutable.

Sin embargo, lo que está intentando hacer actualmente es algo malo en la producción: no se puede garantizar el estado de IIS cuando intenta ejecutar este exe y con razón, IIS no es un Shell.