Erro csc.exe no bin\\roslyn? Top 5 causas e soluções em C#

Introdução: O familiar desconhecido da pasta bin

Você inicia seu projeto em C#, toma um café, ansioso por mais um deploy bem-sucedido, e de repente — bum! — aparece no log ou no navegador aquela mensagem vermelha assustadora: Could not find a part of the path '...\\bin\\roslyn\\csc.exe'. Familiar? Se você já enfrentou o erro csc.exe, sabe que não é apenas "algo quebrou", mas toda uma história sobre como o .NET compila seu código em tempo real.

Na verdade, por trás desse erro não há um destino cruel, mas sim detalhes técnicos bem comuns. Vamos entender por que o bin\\roslyn\\csc.exe de repente "desaparece" e como resolver isso de uma vez por todas. Este artigo será útil tanto para iniciantes que veem esse erro pela primeira vez no ASP.NET, quanto para desenvolvedores experientes que já estão cansados de corrigi-lo manualmente.

O que é esse misterioso csc.exe e para que serve?

Antes de sair resolvendo, vamos entender a teoria. Csc.exe é o compilador C# do .NET Framework. Antes, ele ficava em algum lugar do sistema, mas com o Roslyn (plataforma de compiladores open source da Microsoft), tudo mudou. Agora, em projetos ASP.NET (especialmente os mais antigos, no .NET Framework), é usado o pacote Microsoft.CodeDom.Providers.DotNetCompilerPlatform. Ele copia versões atualizadas do compilador diretamente para a pasta do seu projeto — em bin\\roslyn\\csc.exe.

Por quê? Para que o site possa compilar código C# diretamente no servidor (por exemplo, para views dinâmicas Razor). Se esse arquivo sumiu, foi corrompido ou não foi copiado, você recebe o famoso erro de caminho do csc.exe.

Top 5 causas do erro e como corrigi-las

1. "Sujeira" nas pastas bin e obj (a causa mais comum)

O cenário mais comum: você atualizou pacotes, mudou a versão do .NET, ou o projeto simplesmente "acumulou" builds antigas. As pastas bin e obj armazenam o cache de compilação, e se sobrarem referências quebradas para versões antigas do Roslyn — pronto, erro na certa.

Solução: Limpe o projeto completamente.

// Feche o Visual Studio\n// Exclua manualmente as pastas bin e obj em toda a solução\n// Ou use o console do gerenciador de pacotes:\nUpdate-Package –reinstall Microsoft.CodeDom.Providers.DotNetCompilerPlatform\n

Depois disso, recompile o projeto (Build → Rebuild Solution). O sistema copiará novamente o csc.exe do pacote NuGet para a pasta correta.

2. Conflito de versões dos pacotes NuGet

Às vezes, você acidentalmente atualiza o Microsoft.CodeDom.Providers.DotNetCompilerPlatform para uma versão incompatível com seu projeto. Ou, ao contrário, um pacote antigo não encontra o novo Roslyn.

Solução: Reinstale o pacote à força.

// No console do gerenciador de pacotes (Tools → NuGet Package Manager → Package Manager Console)\nUninstall-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -Force\nInstall-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform\n

Atenção: se seu projeto usa .NET Framework 4.7.2 ou inferior, é melhor instalar a versão 2.0.1 do pacote (versões mais novas podem exigir .NET 4.8+).

3. Web.config corrompido ou alterações manuais

No arquivo web.config, existe a seção <system.codedom>, que indica qual compilador usar. Se você (ou algum plugin) acidentalmente removeu ou alterou essa seção — o bin\\roslyn\\csc.exe deixará de ser carregado.

Solução: Verifique o web.config. A configuração correta é assim:

<system.codedom>\n    <compilers>\n        <compiler language="c#;cs;csharp" extension=".cs"\n            type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Vers