0
322
VistasNumerosas instancias de VBCSCompiler.exe
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 se detuvo por completo. La CPU se agotó al 100% y la compilación nunca se completó, incluso después de más de 10 minutos.
Abrí el Administrador de tareas de Windows y noté: > 10 tareas VBCSCompiler.exe ejecutándose. Cuando se combinaron, estas tareas enviaron a 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 parecido que puedo encontrar a otra persona que experimente el mismo problema: https://github.com/dotnet/roslyn/issues/2790
Actualizar (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 bits 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 del símbolo del sistema de 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 de VS2015 y realicé un reinicio. Esto no ayudó.
Actualización Parte 2 (8/7) -Hans Passant, ¡muy impresionante redacción! Aunque el problema no sucedió esta vez, eché un vistazo a las cosas que describiste:
En cuanto a los módulos cargados con VBCSCompiler.exe, esto es lo que tengo:
Es interesante que nuestros ensamblajes principales de .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:\Program Files (x86)\MSBuild\14.0\Bin\Microsoft.Build.Tasks.CodeAnalysis.dll) tienen la misma versión y marca de tiempo que la suya: 
Por extraño que parezca, cuando miro el código en ILSpy, veo algo ligeramente diferente: ¿quizás la optimización?
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 de nombre de pip específico pasado a las instancias de VBCSCompiler.exe. Tendré que esperar hasta que vuelva a suceder.
3 Respuestas
Responde la pregunta0
Hmm, no hay un escenario de reproducción obvio y nadie más se queja de esto. Su solución no es inusual en absoluto. Vincular la CPU al 100 % y hacer que el proceso VBCSCompiler trague ~1,5 GB no es muy difícil en un proyecto grande, pero está absolutamente limpio cuando miro el mío.
Primer escenario de falla posible en el que tiene algunos bits beta desinstalados, un problema muy común. Utilice el depurador para echar un vistazo. Use Depurar > Adjuntar al proceso y elija una de las instancias en ejecución. Luego Depurar > Romper todo y Depurar > Ver > Módulos. Preste 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:\Program Files (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, vaya 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 cómo la verificació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 habilita varios modos de falla posibles, del tipo habilitado si su máquina está infectada por el típico malware envuelto en plástico 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 nombre con un nombre especial. Algo que puedes ver en el Administrador de tareas, pestaña Procesos. Use Ver> Seleccionar columnas (Win8 y superior: haga clic con el botón derecho en un encabezado de columna) y marque la opción "Línea de comando": 
Tenga en cuenta el argumento -pipename . Si la llamada File.Exists() devuelve falso , 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 interfiere con el uso normal de la canalización con nombre. Lo primero que consideraría entonces 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.
0
¿Alguna idea de por qué hay tantas de estas tareas ejecutándose?
Roslyn usa un proceso de compilación compartido que mantiene su código compilado en la memoria para su reutilización en compilaciones posteriores. Entonces, la segunda compilación será más rápida, pero como ha visto, hay una sobrecarga de memoria.
¿Alguna forma de evitar que esto suceda?
Sí. A partir de aquí , hay una propiedad de la tarea de compilación en msbuild que desactiva el compilador compartido y se establece en verdadero de forma predeterminada .
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 demás proyectos que necesitan esta configuración.
<PropertyGroup> <UseSharedCompilation>false</UseSharedCompilation> </PropertyGroup>0
A partir del 22 de noviembre de 2015, este problema todavía me sucedía en la edición de la comunidad de Visual Studio 2015. Mi computadora portátil estaba comenzando 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 grupo de aplicaciones en el que se ejecuta su aplicación web.
