2012-03-01 28 views
34

me encontré con la siguiente información sobre los archivos de Microsoft Visual Studio "extra":Desactivación de la .vshost.exe * y archivos varios que se creen en la construcción

What is the purpose of the vshost.exe file?

Mi pregunta es, ¿hay alguna manera que NO puedo hacer que se hagan los archivos .pdb, .manifest y vshost.exe ¿O son absolutamente necesarios?

Me di cuenta de que después de depurarlo, sigue apareciendo como un proceso en ejecución en mi máquina que me preocupa porque ya lo cerré.

+1

Me parece que realmente no entendiste lo que dice en su post. .vshost es necesario para comenzar rápidamente su sesión de depuración. Nada de que preocuparse. – Steve

+0

pero también encontré el vshost.exe corriendo doble – gumuruh

Respuesta

59

Cambie a la configuración de Release. Luego, Project + Properties, pestaña Debug, desmarque la opción "Habilitar el proceso de alojamiento de Visual Studio". Build + Clean, puede eliminar todo lo que quede y no volverá. Que esta opción esté activada por defecto para la versión de lanzamiento es, discutiblemente, un pequeño error pero defendible.

El proceso de alojamiento es una versión alojada personalizada de la CLR. Exactamente lo que hace no está bien documentado, pero está relacionado con la configuración de la seguridad del dominio de aplicación principal. Nunca escuché a nadie quejarse sobre la lucha contra los problemas de CAS sin él, pero luego es inusual apagarlo y su aplicación casi siempre se ejecuta con total confianza cuando se depura del IDE. Sería importante si compila una red compartida en las primeras versiones de .NET. Lo único obvio al desactivarlo es que todo lo que escribas con Console.Write en una aplicación de estilo gui ya no aparecerá en la ventana de resultados. No tiene nada que ver con la velocidad, como se afirma en la respuesta muy votada en el enlace, las DLL del marco principal ya residen en la memoria RAM, ya que VS y MSBuild las usan.

Lo mejor es no preocuparse demasiado por eso. Un proyecto de Instalación e Implementación lo ignorará.

+1

Sería bueno deshabilitarlo de compilaciones para 'proyectos de solo contenido'. –

+0

Gracias. Tuve un proyecto actualizado de VS2008 -> VS2013 que se negó a leer el archivo app.config.Luego me enteré de que estaba buscando XXX.vshost.exe.config, que no se generaba a través de AppDomain.CurrentDomain.SetupInformation.ConfigurationFile. Así que lo apagué como arriba. Luego tuve que cambiar el nombre de mi archivo app.config a {projectName} .config, ponerlo en la carpeta bin y finalmente funcionó. – drzounds

+0

Parece que la opción "Habilitar el proceso de alojamiento de Visual Studio" ya no está presente en VS2017 y parece que el proyecto se ejecuta como el exe definido, en lugar de vshost.exe. Quizás vshost es una cosa del pasado a partir de VS2017? – HotN

1

En cuanto a los archivos vshost, al menos en VS2010:

  • No se generan en la construcción, sino en la selección de la configuración de generación (que se generarán en la liberación cuando seleccionamos la liberación por primera vez) y en estableciendo "Habilitar el proceso de alojamiento de Visual Studio" en verdadero. (Como la depuración de configuración y esta opción establecida en true son valores predeterminados, vshost.exe se creará en bin/debug al abrir VS con proyecto de destino de manera predeterminada.)
  • No se limpian al reconstruir o limpiar el proyecto, pero solo manualmente cuando "Habilite el proceso de alojamiento de Visual Studio" es falso si VS con ese proyecto está abierto. (Y no se generará más al abrir este proyecto.)

Si esta opción de indicador es verdadera y se abre VS con proyecto de destino, este archivo no se puede eliminar como utilizado. Una vez que se desmarca, vshost.exe se puede eliminar inmediatamente.

Resumen: Generar y eliminar estos archivos no está relacionado con el proceso de compilación.

Además, puedo agregar que la opción "Habilitar el proceso de alojamiento de Visual Studio" en los proyectos a los que se hace referencia que son bibliotecas de clase no se considera. Esta opción solo se considera para el proyecto de destino que genera el archivo ejecutable.

Cuestiones relacionadas