Cuando crear y compilar un "hola mundo" aplicación en C#, consigo tres archivos en la carpeta de depuración aparte del exe principal (por ejemplo HelloWorld.exe)¿Cuál es el propósito del archivo vshost.exe?
qué propósito sirven estos archivos?
La característica vshost.exe se introdujo con VS2005 (para responder a su comentario).
El objetivo es sobre todo hacer que el inicio de la depuración sea más rápido: básicamente ya hay un proceso con el marco en ejecución, listo para cargar la aplicación tan pronto como lo desee.
Consulte this MSDN article y this blog post para obtener más información.
El archivo vshost.exe es el ejecutable ejecutado por Visual Studio (ejecutable de Visual Studio Host). Este es el ejecutable que se vincula a Visual Studio y mejora la depuración.
Cuando está distribuyendo su aplicación a otros, no usa los archivos vshost.exe o .pdb (depuración de la base de datos).
Recuerdo que no teníamos un ejecutable de este tipo en VS2003 (pero sí teníamos puntos de interrupción). Puedes profundizar sobre eso? –
Además, el manifiesto son metadatos sobre la aplicación que generalmente también se vinculan al ejecutable. El archivo .pdb es una base de datos portátil de depuración y contiene información de depuración sobre el ejecutable compilado, como qué punto del ejecutable corresponde a qué línea en el código. – Joey
El proceso de host de VS solo se usa para mejorar la depuración, pero no habilita la depuración. –
.exe - el ejecutable 'normal'
.vshost.exe - una versión especial del ejecutable para ayudar debuging; ver MSDN para más detalles
.pdb - la Program Data Base con símbolos de depuración
.vshost.exe.manifest - una especie de configuration file que contiene en su mayoría dependencias de las bibliotecas
no estoy seguro , pero creo que es una optimización de depuración. Sin embargo, normalmente lo desactivo (vea Propiedades de depuración para el proyecto) y no noto ninguna desaceleración y no veo limitaciones en lo que respecta a la depuración, por lo que ciertamente no es necesario para la depuración según lo indicado por Guard.
Parece ser un proceso de marco de larga ejecución para la depuración (para disminuir los tiempos de carga?). Descubrí que cuando inicia su aplicación dos veces desde el depurador, a menudo se usará el mismo proceso vshost.exe. Simplemente descarga todas las DLL cargadas por el usuario primero. Esto hace cosas extrañas si estás jugando con los ganchos API de los procesos gestionados.
El proceso persistente también causa una excepción (violación de acceso) cuando mi proyecto tiene algún código para hacer P/Invocar. El problema desapareció después de deshabilitar el proceso de host. – Thomson
Añadiendo, puede desactivar la creación de archivos vshost para su configuración de generación lanzamiento y tenerlo habilitado depuración.
Pasos
Referencia
Extracto de MSDN How to: Disable the Hosting Process
pueden verse afectados llamadas a determinadas API cuando el proce de alojamiento ss está habilitado. En estos casos, es necesario deshabilitar el proceso de alojamiento para devolver los resultados correctos.
para desactivar el proceso de alojamiento
Cuando el proceso de alojamiento está deshabilitado, varias características de depuración no están disponibles o experimentan un rendimiento reducido. Para obtener más información, consulte Debugging and the Hosting Process.
En general, cuando el proceso de alojamiento está desactivada:
- El tiempo necesario para iniciar la depuración de aplicaciones .NET Framework aumenta.
- La evaluación de la expresión en tiempo de diseño no está disponible.
- La depuración de confianza parcial no está disponible.
Esta es la razón por la cual cuando ejecuto Console.Write (System.AppDomain.CurrentDomain.FriendlyName) desde el depurador, obtengo app.vshost.exe y cuando ejecuto directamente desde el exe obtengo la salida como app.exe – Milen
Gracias por responder mi comentario ¡Era una de las cosas que no sabía desde que VS2005 y yo eramos demasiado vagos y no nos importó lo suficiente como para buscar y aprender! –
@Milen, http://msdn.microsoft.com/en-us/library/ms242202.aspx mencionó el resultado diferente de AppDomain.CurrentDomain.FriendlyName con y sin proceso de host. – Thomson