ES
RU
EN
ZH
FR
DE
PT
AR
HI
Introducción: El conocido desconocido de la carpeta bin
\n\nEjecutas tu proyecto en C#, bebes café, anticipando otro despliegue exitoso, y de repente — ¡bam! — en los registros o en el navegador aparece un aterrador mensaje en rojo: Could not find a part of the path '...\\bin\\roslyn\\csc.exe'. ¿Te suena? Si alguna vez te has topado con el error de csc.exe, sabes que no es solo "algo se rompió", sino toda una historia sobre cómo .NET compila tu código sobre la marcha.
En realidad, detrás de este error no hay un destino adverso, sino simples matices técnicos. Analicemos por qué bin\\roslyn\\csc.exe de repente "desaparece" y cómo solucionarlo de una vez por todas. El artículo será útil tanto para principiantes que ven este error por primera vez en ASP.NET, como para desarrolladores experimentados que están cansados de repararlo manualmente.
\n\n¿Qué es ese misterioso csc.exe y para qué sirve?
\n\nAntes de lanzarnos a la batalla, entendamos la teoría. Csc.exe es el compilador de C# del .NET Framework. Antes vivía en algún lugar del sistema, pero con la llegada de Roslyn (la plataforma de compiladores de código abierto de Microsoft) todo cambió. Ahora, en proyectos ASP.NET (especialmente los antiguos, en .NET Framework) se utiliza el paquete Microsoft.CodeDom.Providers.DotNetCompilerPlatform. Este copia las versiones más recientes del compilador directamente en la carpeta de tu proyecto — en bin\\roslyn\\csc.exe.
¿Para qué? Para que el sitio pueda compilar código C# directamente en el servidor (por ejemplo, para vistas dinámicas Razor). Si este archivo falta, está dañado o no se copió, obtienes el famoso error de ruta a csc.exe.
\n\nTop 5 causas del error y cómo solucionarlas
\n\n1. "Basura" en las carpetas bin y obj (la causa más común)
\n\nEl escenario más popular: actualizaste paquetes, cambiaste la versión de .NET, o simplemente el proyecto se "ensució" con compilaciones antiguas. Las carpetas bin y obj almacenan el caché de compilación, y si quedan referencias rotas a versiones antiguas de Roslyn — hola, error.
Solución: Limpia el proyecto "por completo".
\n\n// Cierra Visual Studio\n// Elimina manualmente las carpetas bin y obj en toda la solución\n// O usa la consola del administrador de paquetes:\nUpdate-Package –reinstall Microsoft.CodeDom.Providers.DotNetCompilerPlatform\nDespués de esto, recompila el proyecto (Build → Rebuild Solution). El sistema copiará de nuevo el csc.exe desde el paquete NuGet a la carpeta correspondiente.
\n\n2. Conflicto de versiones de paquetes NuGet
\n\nA veces actualizas accidentalmente Microsoft.CodeDom.Providers.DotNetCompilerPlatform a una versión incompatible con tu proyecto. O, por el contrario, un paquete antiguo no encuentra el nuevo Roslyn.
\n\nSolución: Reinstala el paquete de forma forzada.
\n\n// En la consola del administrador de paquetes (Tools → NuGet Package Manager → Package Manager Console)\nUninstall-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -Force\nInstall-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform\nTen en cuenta: si tu proyecto usa .NET Framework 4.7.2 o inferior, es mejor instalar la versión del paquete 2.0.1 (las más nuevas pueden requerir .NET 4.8+).
3. web.config incorrecto o modificaciones manuales
\n\nEn el archivo web.config hay una sección <system.codedom> que indica qué compilador usar. Si tú (o algún plugin) eliminaste o modificaste accidentalmente esta sección — bin\\roslyn\\csc.exe dejará de conectarse.
Solución: Revisa web.config. La configuración correcta se ve así:
\n\n<system.codedom>\n <compilers>\n <compiler language="c#;cs;csharp" extension=".cs"\n type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Vers 
