Erreur csc.exe dans bin\\roslyn : Top 5 causes et solutions C#

Introduction : Ce mystérieux fichier du dossier bin

Vous lancez votre projet C#, sirotez votre café en attendant un déploiement réussi, et soudain — bam ! — un message rouge effrayant apparaît dans les logs ou le navigateur : Could not find a part of the path '...\\bin\\roslyn\\csc.exe'. Ça vous dit quelque chose ? Si vous avez déjà rencontré l'erreur csc.exe, vous savez que ce n'est pas juste un « petit bug », mais toute une histoire sur la façon dont .NET compile votre code à la volée.

En réalité, derrière cette erreur ne se cache pas un mauvais sort, mais de simples subtilités techniques. Voyons pourquoi bin\\roslyn\\csc.exe disparaît soudainement et comment y remédier définitivement. Cet article sera utile aussi bien aux débutants qui voient cette erreur pour la première fois dans ASP.NET qu'aux développeurs expérimentés qui en ont assez de la corriger manuellement.

Qu'est-ce que ce mystérieux csc.exe et à quoi sert-il ?

Avant de foncer tête baissée, faisons un peu de théorie. Csc.exe est le compilateur C# du .NET Framework. Avant, il se cachait dans les tréfonds du système, mais avec l'arrivée de Roslyn (la plateforme de compilateurs open source de Microsoft), tout a changé. Désormais, dans les projets ASP.NET (surtout les anciens, sous .NET Framework), on utilise le package Microsoft.CodeDom.Providers.DotNetCompilerPlatform. Il copie les versions récentes du compilateur directement dans le dossier de votre projet, dans bin\\roslyn\\csc.exe.

Pourquoi ? Pour que le site puisse compiler du code C# directement sur le serveur (par exemple, pour les vues dynamiques Razor). Si ce fichier est manquant, corrompu ou n'a pas été copié, vous obtenez la fameuse erreur de chemin vers csc.exe.

Top 5 des causes de l'erreur et comment les corriger

1. « Crasse » dans les dossiers bin et obj (la cause la plus fréquente)

Le scénario le plus courant : vous avez mis à jour des packages, changé la version de .NET, ou le projet est simplement « encrassé » par d'anciennes assemblies. Les dossiers bin et obj stockent le cache de compilation, et s'il reste des références cassées vers d'anciennes versions de Roslyn — bonjour l'erreur.

Solution : Nettoyez le projet de fond en comble.

// Fermez Visual Studio\n// Supprimez manuellement les dossiers bin et obj dans toute la solution\n// Ou utilisez la console du gestionnaire de packages :\nUpdate-Package –reinstall Microsoft.CodeDom.Providers.DotNetCompilerPlatform\n

Ensuite, reconstruisez le projet (Build → Rebuild Solution). Le système recopiera csc.exe depuis le package NuGet dans le bon dossier.

2. Conflit de versions des packages NuGet

Il arrive que vous mettiez à jour Microsoft.CodeDom.Providers.DotNetCompilerPlatform vers une version incompatible avec votre projet. Ou, à l'inverse, qu'un ancien package ne trouve pas le nouveau Roslyn.

Solution : Réinstallez le package de force.

// Dans la console du gestionnaire de packages (Tools → NuGet Package Manager → Package Manager Console)\nUninstall-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -Force\nInstall-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform\n

Attention : si votre projet utilise .NET Framework 4.7.2 ou inférieur, installez de préférence la version 2.0.1 du package (les versions plus récentes peuvent nécessiter .NET 4.8+).

3. Fichier web.config corrompu ou modifications manuelles

Dans le fichier web.config, il y a une section <system.codedom> qui indique quel compilateur utiliser. Si vous (ou un plugin) avez accidentellement supprimé ou modifié cette section, bin\\roslyn\\csc.exe ne sera plus chargé.

Solution : Vérifiez votre web.config. La configuration correcte ressemble à ceci :

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