visual studio net descargar community caracteristicas c# .net visual-studio-2015 roslyn

c# - net - visual studio installer



Numerosas instancias de VBCSCompiler.exe (7)

¿Alguna idea de por qué hay tantas de estas tareas ejecutándose?

Roslyn utiliza un proceso de compilador compartido que mantiene el código compilado en la memoria para reutilizarlo en compilaciones posteriores. Entonces la segunda compilación será más rápida, pero como has visto, hay una sobrecarga de memoria.

¿Alguna forma de evitar que esto suceda?

Sí. A partir de here hay una propiedad de la tarea de compilación en msbuild que desactiva el compilador compartido, y se establece en verdadero de default .

Entonces, en cada proyecto, deberá agregar esta propiedad al archivo del proyecto. O en Visual Studio 2015 ahora hay proyectos compartidos, donde puede agregar esta propiedad al proyecto compartido y luego incluir ese proyecto compartido en todos los otros proyectos que necesitan esta configuración.

<PropertyGroup> <UseSharedCompilation>false</UseSharedCompilation> </PropertyGroup>

Recientemente descargué e instalé Visual Studio Professional 2015 (14.0.23107.0). La primera vez que abrí nuestra solución (28 proyectos) y realicé una Solución Build -> Rebuild, mi máquina de desarrollo llegó a un rastreo absoluto. La CPU se maximizó al 100% y la compilación nunca se completó, incluso después de> 10 minutos.

Abrí el Administrador de tareas de Windows y noté:> 10 tareas de VBCSCompiler.exe ejecutándose. Cuando se combinan, estas tareas enviaron la CPU> 90%.

¿Alguna idea de por qué hay tantas de estas tareas ejecutándose? ¿Alguna forma de evitar que esto suceda?

Esto es lo más cercano que puedo encontrar a alguien que experimente el mismo problema: https://github.com/dotnet/roslyn/issues/2790

Actualización (8/7)

-Hans Passant, gran pensamiento. Mi gerente me proporcionó esta versión (14.0.23107.0). ¿Es esta la versión correcta para el "lanzamiento oficial"? No instalé a sabiendas ninguna de las versiones por lanzamiento de Visual Studio 2015. No creo que haya versiones beta por ahí.

-Kyle Trauberman, no estoy tan familiarizado con las variables de entorno en el contexto de Visual Studio; sin embargo, ingenuamente ejecuté set DisableRosyln=true en una ventana de símbolo del sistema VS (y MSBuild). Esto no pareció tener ningún impacto. VBCSCompiler.exe mostró una copia de seguridad incluso después de reiniciar VS2015.

Reparé mi instalación VS2015 y realicé un reinicio. Esto no ayudó.

Actualización Parte 2 (8/7) -Hans Passant, muy impresionante escribir !! Aunque, el problema no sucedió esta vez, eché un vistazo a las cosas que describiste:

En cuanto a los módulos cargados con el VBCSCompiler.exe, esto es lo que tengo:

Es interesante que nuestros ensambles principales .NET estén en diferentes versiones. Estás en 4.06.79 mientras que yo estoy en 4.06.81.

Mis "dlls del lado del cliente" (ubicados en C: / Archivos de programa (x86) / MSBuild / 14.0 / Bin / Microsoft.Build.Tasks.CodeAnalysis.dll) están en la misma versión y sello de tiempo que el suyo:

Por extraño que parezca, cuando miro el código en ILSpy, veo algo ligeramente diferente: ¿optimización quizás?

private static NamedPipeClientStream TryAllProcesses(string pipeName, int timeoutMs, CancellationToken cancellationToken, out string newPipeName) { string str = pipeName; int num = 1; while (File.Exists(string.Format("////.//pipe//{0}", pipeName))) { NamedPipeClientStream result; if ((result = BuildClient.TryConnectToProcess(pipeName, timeoutMs, cancellationToken)) != null) { newPipeName = pipeName; return result; } pipeName = str + "." + num.ToString(CultureInfo.InvariantCulture); num++; } newPipeName = pipeName; return null; }

** Permítame volver con usted sobre el argumento específico de nombre de pip pasado a las instancias de VBCSCompiler.exe. Tendré que esperar hasta que vuelva a suceder.

A partir del 22 de noviembre de 2015, este problema todavía me sucedía en la edición comunitaria de Visual Studio 2015. Mi computadora portátil comenzaba a funcionar como un calentador de espacio con todas las instancias de VBCSCompiler funcionando a toda velocidad.

La única solución que funcionó para mí fue ubicar el archivo VBCSCompiler.exe en el directorio / bin / roslyn de la aplicación web y cambiar los permisos de seguridad en él.

Debe denegar el permiso de lectura y ejecución para el AppPool con el que se ejecuta su aplicación web.

Descubrí que cambiar la identidad a ''NetworkService'' en la configuración avanzada del grupo de aplicaciones solucionó el problema para mí.

Hmm, no hay un escenario obvio de repro y nadie más se queja de esto. Su solución no es inusual en absoluto. Fijar la CPU al 100% y hacer que el proceso de VBCSCompiler se trague ~ 1.5 GB no es muy difícil en un proyecto grande, pero es extremadamente limpio cuando miro el mío.

Primer posible escenario de falla en el que tiene algunos bits beta desinstalados por ahí, un problema muy común. Use el depurador para tener un look-see. Use Debug> Attach to Process y elija una de las instancias en ejecución. Luego Depuración> Romper todo y Depuración> Ver> Módulos. Presta atención a los números de versión y las marcas de tiempo, deberían verse así:

Tenga en cuenta que intencionalmente ocultó algunas columnas para mantenerlo legible. Las marcas de tiempo son la zona horaria CST.

Ese es el lado del servidor. El lado del cliente que tenía el error que descubrió se encuentra en C: / Archivos de programa (x86) / MSBuild / 14.0 / Bin / Microsoft.Build.Tasks.CodeAnalysis.dll. Eche un vistazo a sus propiedades, la mía tiene 85,192 bytes y se creó el domingo 21 de junio de 2015 a las 7:06:54 p.m., número de versión del archivo 1.0.0.50618. Puede mirar el archivo con un descompilador como Reflector o ILSpy, navegar a BuildClient. TryAllProcesses (). La línea relevante con la corrección de errores es:

for (int i = 1; File.Exists(string.Format(@"//./pipe/{0}", pipeName)); i++)

Faltaba la versión con errores //./pipe/ .

Tenga en cuenta que la comprobación de errores es muy inadecuada en el fragmento anterior, File.Exists () devuelve falso por muchas razones. También la razón básica por la que el error no se descubrió antes. Eso permite varios modos de falla posibles, el tipo habilitado si su máquina está infectada por el típico malware encogido que los programadores instalan voluntariamente. El servidor y el código del cliente se conectan entre sí a través de una tubería con un nombre especial. Algo que puede ver en el Administrador de tareas, pestaña Procesos. Use Ver> Seleccionar columnas (Win8 y superior: haga clic con el botón derecho en el encabezado de una columna) y marque la opción "Línea de comando":

Tenga en cuenta el argumento -pipename . Si la llamada File.Exists () devuelve false , MSBuild iniciará VBCSCompiler.exe nuevamente. Si ve que todas estas instancias se ejecutan con el mismo argumento -pipename, entonces tiene un software ejecutándose en su máquina que está interfiriendo con el uso normal de tuberías con nombre. Lo primero que consideraría es buscar una solución antimalware menos agresiva. Puede escribir un pequeño programa de prueba que use el espacio de nombres System.IO.Pipes para obtener un mejor mensaje de excepción.

También encontré este problema con Visual Studio Enterprise 2015, Actualización 1. El problema se resolvió actualizando a la Actualización 2.

También puede cambiar la opción "mantener vivo" para VBCSCompiler, para cerrarlo justo después de la ejecución ... Debe modificar el archivo "VBCSCompiler.exe.config" ("C: / Archivos de programa (x86) / MSBuild / 14.0 / Bin / VBCSCompiler.exe.config ") y establece el valor necesario en segundos (por defecto es 600).