Le type de fournisseur CodeDom «Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider» n'a pas pu être localisé

C'est un projet WebApi utilisant VS2015.

Étape pour reproduire:

1. Créer un projet WebApi vide
2. Changez le chemin de sortie de la construction de "bin \" à "bin \ Debug \"
3. Courir

Tout fonctionne parfaitement jusqu'à ce que je change le chemin de sortie de la construction de "bin \" à "bin \ Debug \". En fait, tout chemin de sortie autre que "bin \" ne fonctionnera pas.

Une petite chose supplémentaire est que, avoir un autre chemin de sortie n'importe où fonctionnerait tant que je laisserais une construction dans "bin \".

Veuillez aider à fournir une solution pour résoudre ce problème. Je suppose que cela coûtera un problème lors du déploiement réel.

Si votre projet a des références Roslyn et que vous le déployez sur un serveur IIS , vous risquez d'obtenir des erreurs indésirables sur le site Web, car de nombreux fournisseurs d'hébergement n'ont toujours pas mis à niveau leurs serveurs et ne prennent donc pas en charge Roslyn.

Pour résoudre ce problème, vous devrez supprimer le compilateur Roslyn du modèle de projet . La suppression de Roslyn ne devrait pas affecter les fonctionnalités de votre code. Cela a bien fonctionné pour moi et pour certains autres projets (C # 4.5.2) sur lesquels j'ai travaillé.

Suivez les étapes suivantes:

1. Supprimez les packages Nuget suivants en utilisant la ligne de commande ci-dessous ( ou vous pouvez utiliser l'interface graphique du gestionnaire de packages Nuget en cliquant avec le bouton droit de la souris sur Root Project Solution et en les supprimant ).

   PM> Uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform
   PM> Uninstall-package Microsoft.Net.Compilers

2. Supprimez le code suivant de votre fichier Web.Config et redémarrez IIS . ( N'utilisez cette méthode que si l'étape 1 ne résout pas votre problème. )

   <system.codedom>
   <compilers>
     <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:6 /nowarn:1659;1699;1701" />
     <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:14 /nowarn:41008 /define:_MYTYPE=\&quot;Web\&quot; /optionInfer+" />
   </compilers>

Faites attention de suivre les conseils de cette réponse. Bien que cela résout le problème en question, cela peut entraîner des problèmes différents à une date ultérieure.

J'ai le même problème. Apparemment, le compilateur .NET n'a pas été chargé dans le GAC. Ce que j'ai fait pour le résoudre était:

Tout d'abord, dans le type de console du gestionnaire de packages:

PM> Install-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform

Maintenant, pour une raison quelconque, les gentils messieurs de Microsoft ont décidé de ne pas l'installer sur le GAC pour nous. Vous pouvez le faire manuellement en ouvrant l'invite de commande du développeur et en tapant:

gacutil -i "C:\*PATH TO YOUR APP CODE*\bin\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.dll"

Conclusion

Microsoft essaie d'encourager tout le monde à tout faire avec des nugets, ce qui pourrait bien fonctionner sans les bogues occasionnels que vous rencontrez avec le système nuget. Essayez d'utiliser le même projet sur différentes solutions, mettez à jour accidentellement (ou non) l'une des nombreuses pépites qu'il utilise sur l'une d'entre elles, et si vous n'êtes pas chanceux, vous verrez ce que je veux dire lorsque vous essayez de construire l'autre solution. D'un autre côté, placer des fichiers dans le GAC peut également causer des problèmes futurs, car les gens ont tendance à oublier ce qu'ils y mettent et, lors de la configuration de nouveaux environnements, ils oublient d'inclure ces fichiers. Une autre solution possible est de placer les fichiers dans un dossier central pour les DLL tierces (même s'il est étrange d'appeler le compilateur tiers), ce qui crée des problèmes de références brisées lors de la configuration de nouveaux environnements. Si vous décidez d'installer la dll sur le GAC, soyez prudent et rappelez-vous que vous l'avez fait. Si vous ne le faites pas, téléchargez à nouveau le nuget pour chaque projet et supportez tous les bugs gênants causés par celui-ci (du moins, cela se produisait lorsque j'en avais enfin marre et que je plaçais les fichiers dans le GAC). Les deux approches peuvent vous donner des maux de tête et créer des problèmes, c'est juste une question de savoir quels problèmes vous préférez traiter. Microsoft recommande d'utiliser le système nuget, et généralement, il est préférable de les écouter que d'un programmeur inconnu dans SO, à moins que vous ne soyez complètement malade du système nuget et que vous ayez l'habitude de traiter avec le GAC assez longtemps pour que ce soit une meilleure alternative pour vous. téléchargez à nouveau le nuget pour chaque projet et supportez tous les bugs gênants causés par celui-ci (du moins, cela se produisait lorsque j'en avais enfin marre et que je plaçais les fichiers dans le GAC). Les deux approches peuvent vous donner des maux de tête et créer des problèmes, c'est juste une question de savoir quels problèmes vous préférez traiter. Microsoft recommande d'utiliser le système nuget, et généralement, il est préférable de les écouter que d'un programmeur inconnu dans SO, à moins que vous ne soyez complètement malade du système nuget et que vous ayez l'habitude de traiter avec le GAC assez longtemps pour que ce soit une meilleure alternative pour vous. téléchargez à nouveau le nuget pour chaque projet et supportez tous les bugs gênants causés par celui-ci (du moins, cela se produisait lorsque j'en avais enfin marre et que je plaçais les fichiers dans le GAC). Les deux approches peuvent vous donner des maux de tête et créer des problèmes, c'est juste une question de savoir quels problèmes vous préférez traiter. Microsoft recommande d'utiliser le système nuget, et généralement, il est préférable de les écouter que d'un programmeur inconnu dans SO, à moins que vous ne soyez complètement malade du système nuget et que vous ayez l'habitude de traiter avec le GAC assez longtemps pour que ce soit une meilleure alternative pour vous.

Ajoutez simplement le package nuget suivant à votre projet - Microsoft.CodeDom.Providers.DotNetCompilerPlatform.

Avait le même problème.

J'ai le même problème que mon application fonctionnait dans Vs2013 mais obtenant l'erreur après la mise à jour vers Vs2015.

1. Dans Vs2015, cliquez avec le bouton droit sur le dossier Références du projet pour ouvrir NuGet Package Manager
2. Sous l'onglet Parcourir, recherchez «DotNetCompilerPlatform» et installez la bibliothèque «Microsoft.CodeDom.Providers.DotNetCompilerPlatform»

Je sais que c'est un ancien fil, mais j'aimerais signaler le problème de version possible de DotNetCompilerPlatform.dll, f. ex. après une mise à jour. Veuillez vérifier si le nouveau fichier Web.config généré est différent de votre web.config publié, en particulier la partie system.codedom. Dans mon cas, c'était le changement de version de 1.0.7 à 1.0.8. La nouvelle dll avait déjà été copiée sur le serveur, mais je n'ai pas changé l'ancien web.config (avec quelques paramètres spéciaux du serveur):

<pre>
  <system.codedom>
    <compilers>
      <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.8.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:default /nowarn:1659;1699;1701" />
      <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.8.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" warningLevel="4" compilerOptions="/langversion:default /nowarn:41008 /define:_MYTYPE=\&quot;Web\&quot; /optionInfer+" />
    </compilers>
  </system.codedom>
</pre>

Après avoir mis à jour les deux lignes, l'erreur a disparu.

Selon vos étapes de repro, j'ai supposé que changer le chemin de sortie dans la propriété de l'application était votre seul changement après avoir créé l'application. La seule chose que cette modification fait est qu'elle indique à Visual Studio de placer les assemblys de sortie de MSBuild dans le nouveau dossier. Au moment de l'exécution, cependant, ASP.Net n'aurait aucune idée qu'il devrait charger des assemblys à partir de ce nouveau dossier au lieu du dossier \ bin.

Cette réponse montre comment modifier le répertoire de sortie de construction d'une application WebApi. Pour obtenir exactement la même erreur que celle indiquée dans cet article, vous devez commenter toute la section <system.codedom> dans web.config. Et puis vous pouvez suivre les instructions pour changer le chemin de sortie.

Une fois que votre application fonctionne, vous pouvez décommenter la section <system.codedom>. Si vous n'utilisez pas du tout la nouvelle syntaxe C # 6 dans votre application, vous pouvez désinstaller Microsoft.CodeDom.Providers.DotNetCompilerPlatform de votre application; sinon, vous voudrez peut-être ajouter la ligne de commande suivante dans votre événement post-build,

xcopy /Q /Y "$(TargetDir)roslyn\*.*" "$(TargetDir)..\roslyn\"

Le nouveau fournisseur CodeDom recherche toujours le dossier "\ roslyn" dans \ bin. La commande ci-dessus fonctionne comme une solution de contournement et copie le dossier \ roslyn de votre nouveau dossier de sortie vers \ bin.

Dans mes expériences, l'outil de publication de Visual Studio a cependant publié les assemblys de sortie dans le dossier \ bin de l'emplacement de déploiement, quel que soit le paramètre de chemin de sortie. Je suppose que votre application devrait toujours fonctionner sur un déploiement réel.

Méthode simple - Projet> Gérer les packages NuGet ...> Parcourir (onglet)> dans l'entrée de recherche, définissez ceci: Microsoft.CodeDom.Providers.DotNetCompilerPlatform

Vous pouvez installer ou mettre à jour ou désinstaller et installer ce compilateur

Une autre solution possible:

Redémarrez votre instance Visual Studio avec des droits d'administrateur

Il s'est arrêté après la publication sur le serveur de production. La raison pour laquelle il m'a montré cette erreur était parce qu'il a été déployé dans un sous- dossier. Dans IIS, j'ai cliqué à droite sur le sous-dossier et excuté "Convertir en application" et après cela, cela a fonctionné.

Dans mon cas, cela s'est produit lorsque je modifie l'autorisation du dossier d'application et que le compte IIS_IUSRS a été supprimé. Après avoir ré-ajouté IIS_IUSRS (Gestionnaire IIS-> YourWebApp -> Modifier l'autorisation -> Ajouter IIS_IUSRS) au dossier de l'application et son fonctionnement.

Voici comment je l'ai résolu :

1. Supprimé le bindossier dans le répertoire du projet.
2. Cliquez sur Build Solution. Dans VS2017 (Exécuter en tant qu'administrateur)> Build> Build Solution .

Si vous utilisez git, vous ignorez probablement le .dll dans le commit

J'avais un certain nombre de projets dans la solution et le projet Web (problème donnant cette erreur) n'a pas été défini comme projet de démarrage. J'ai défini ce projet Web comme projet de démarrage, et j'ai cliqué sur l'élément de menu "Déboguer" -> "Démarrer le débogage" et cela a fonctionné. J'ai arrêté le débogage, puis j'ai essayé à nouveau et maintenant il fonctionne de nouveau. Bizarre.

Puis le problème est revenu. Je désinstallé à la fois Microsoft.CodeDom.Providers.DotNetCompilerPlatformet , Uninstall-package Microsoft.Net.Compilersmais aucune aide. Puis installé - aucune aide. Projet nettoyé et construit aucune aide. Serveur redémarré sans aide.Ensuite, j'ai remarqué que le projet n'avait pas besoin du dernier qui est actuellement 1.0.5 mais 1.0.3 car c'était l'erreur ne pouvait pas charger la version 1.0.3. J'ai donc installé cette version dll à la place et maintenant cela fonctionne.

ASP.NET ne recherche bin/debugni aucun sous-dossier sous bin pour les assemblys comme le font les autres types d'applications. Vous pouvez demander au runtime de chercher dans un endroit différent à l'aide de la configuration suivante:

<configuration>
   <runtime>   
      <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
         <probing privatePath="bin;bin\Debug;bin\Release"/>
      </assemblyBinding>
   </runtime>   
</configuration>

Vous devez mettre à jour les packages «Microsoft.CodeDom.Providers.DotNetCompilerPlatform» et «Microsoft.Net.Compilers» dans votre projet.

Dans mon cas, j'ai eu l'erreur lorsque j'avais mon application Web en 4.5.2 et les bibliothèques de classes référencées en 4.6.1. Lorsque j'ai mis à jour l'application Web vers la version 4.5.2, l'erreur a disparu.

J'obtenais cette erreur car l'utilisateur de mon pool d'applications était défini sur ApplicationPoolIdentity. Je l'ai changé en un compte utilisateur / service qui a accès au dossier et l'erreur a disparu.

Voici mes conclusions. J'ai également fait face à ce problème aujourd'hui matin. Je viens d'ajouter mon utilisateur actuel au pool d'applications sur lequel l'application était en cours d'exécution.

Pas:

1. Ouvrez IIS

2. Cliquez sur le pool d'applications

3. Sélectionnez votre pool d'applications sur lequel vous rencontrez un problème

4. Clic droit -> paramètres avancés

5. Cliquez sur l'icône à trois points à côté de l' identité

6. Maintenant, sélectionnez un compte personnalisé

7. Donnez le nom d'utilisateur et le mot de passe de votre PC

8. sauver

Actualisez votre application .. et elle commencera à fonctionner. Il y avait un problème de sécurité pour accéder à la DLL.

désinstallez simplement le package de la console du gestionnaire de packages à partir de la commande ci-dessous

PM> Package de désinstallation Microsoft.CodeDom.Providers.DotNetCompilerPlatform

PM> Désinstaller-package Microsoft.Net.Compilers

puis réinstallez-le à partir du gestionnaire de nuget

Si vous avez récemment installé ou mis à jour le Microsoft.CodeDom.Providers.DotNetCompilerPlatformpackage, vérifiez que les versions de ce package référencées dans votre projet pointent vers la version correcte et identique de ce package:

• Dans ProjectName.csproj, assurez-vous qu'une <Import>balise pour Microsoft.CodeDom.Providers.DotNetCompilerPlatformest présente et pointe vers la version correcte.

• Dans ProjectName.csproj, assurez-vous qu'une <Reference>balise pour Microsoft.CodeDom.Providers.DotNetCompilerPlatformest présente et pointe vers la version correcte, à la fois dans l' Includeattribut et dans l'enfant <HintPath>.

• Dans ce projet web.config, assurez-vous que la <system.codedom>balise est présente et que ses <compiler>balises enfants ont la même version dans leur typeattribut.

Pour une raison quelconque, dans mon cas une mise à jour de ce paquet de 1.0.5 à 1.0.8 causé la <Reference>balise dans le .csprojd'avoir son Includepointage à l'ancienne version 1.0. 5 .0 (que j'avais supprimé après la mise à niveau du package), mais tout le reste pointait vers la nouvelle version correcte 1.0. 8 .0.

Assurez-vous que votre projet est entièrement construit!

Cliquez sur l'onglet 'Sortie' et assurez-vous que vous n'avez pas quelque chose comme:

========== Tout reconstruire: 14 réussi, 1 échec, 0 ignoré =========

Et ouvrez votre bindossier et vérifiez s'il est à jour.

J'ai eu tout un tas d'erreurs dactylographiées que j'ai ignorées au début, oubliant qu'elles cassaient la construction et conduisaient à ce qu'aucune DLL ne soit copiée.

Ajoutez une référence à l'assembly CppCodeProvider.

Dans mon cas, mon projet Web n'était pas chargé correctement (il montrait le projet indisponible), puis j'ai dû recharger mon projet Web après avoir ouvert mon studio visuel en mode administrateur, puis tout fonctionnait bien.

J'ai juste eu le même problème et c'est parce que j'ai déplacé l'emplacement du projet et que j'avais simplement besoin de recréer le répertoire virtuel.

L'exception que nous avons rencontrée n'était pas sur le serveur local mais sur le serveur distant, Azure CI la lisait à partir du dossier packages mais les versions du compilateur mentionnées ci-dessus n'ont pas été trouvées.

Pour résoudre ce problème, nous avons modifié le fichier du projet pour en faire quelque chose comme

Il ne fait référence à aucun des packages ici référençant directement les variables d'environnement.

Cela a résolu le problème, mais dans nos cas, nous n'utilisons pas les packages directement à partir de "package.config" à la place, nous avons un dossier séparé pour maintenir l'intégrité des versions entre les équipes.

Accédez à inetmgr à partir de la commande de démarrage Dans la console du gestionnaire IIS, choisissez le dossier d'application sous Site Web par défaut, cliquez avec le bouton droit sur ce dossier, puis Convertir en application Exécutez le fichier .asmx en l'activant. Il a résolu le problème

Vérifiez si le BINdossier est téléchargé complètement ou s'il manque dans les fichiers.

Concernant cette erreur, j'ai essayé:

• Nettoyage et reconstruction du projet
• Déchargement et rechargement du projet
• Modification du cadre cible
• Modification du chemin de sortie
• Ajouter des pépites au GAC
• Supprimer les packages uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform uninstall-package Microsoft.Net.Compilerset les réinstaller.

Bien que toutes ces solutions semblent valables, je n'ai pu générer que de nouvelles erreurs et à la fin, l'erreur semble pouvoir s'afficher lorsque certaines références / pépites sont manquantes.

Dans mon cas, j'avais récemment réinstallé Microsoft Office et référençais des assemblys comme Microsoft.Office.Core. La nouvelle installation ne semblait pas inclure les packages requis, ce qui empêchait ma solution de se construire correctement.

J'ai pu résoudre ce problème en retravaillant mon code au point que je n'avais pas besoin de faire référence à Microsoft.Office, mais j'aurais pu le résoudre en recherchant les packages requis et en les installant en conséquence.

Cela ressemble à un message d'erreur peu clair de Visual Studio.

Si vous avez travaillé sur un projet et que cela vient de s'afficher comme une erreur. Redémarrez votre ordinateur (ou serveur dans mon cas), cela a résolu le problème pour moi.