No se pudo encontrar el tipo de proveedor de CodeDom "Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider"

Es un proyecto de WebApi que usa VS2015.

Paso para reproducir:

1. Crear un proyecto WebApi vacío
2. Cambie la ruta de salida de Build de "bin \" a "bin \ Debug \"
3. correr

Todo funciona perfectamente hasta que cambie la ruta de salida de compilación de "bin \" a "bin \ Debug \". De hecho, cualquier ruta de salida que no sea "bin \" no funcionará.

Una pequeña cosa adicional es que, tener otra ruta de salida a cualquier lugar funcionaría siempre que deje una compilación en "bin \".

Por favor, ayuda a proporcionar una solución para resolver esto. Supongo que costará un problema en la implementación real.

Si su proyecto tiene referencias de Roslyn y lo está implementando en un servidor IIS , es posible que obtenga errores no deseados en el sitio web, ya que muchos proveedores de alojamiento todavía no han actualizado sus servidores y, por lo tanto, no son compatibles con Roslyn.

Para resolver este problema, deberá eliminar el compilador de Roslyn de la plantilla del proyecto . Eliminar Roslyn no debería afectar la funcionalidad de su código. Funcionó bien para mí y algunos otros proyectos (C # 4.5.2) en los que trabajé.

Haz los siguientes pasos:

1. Elimine de los siguientes paquetes de Nuget usando la línea de comando que se muestra a continuación ( o puede usar la GUI del administrador de paquetes de Nuget haciendo clic derecho en la solución de proyecto raíz y eliminándolos ).

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

2. Elimine el siguiente código de su archivo Web.Config y reinicie IIS . ( Use este método solo si el paso 1 no resuelve su problema ) .

   <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>

Tenga cuidado de seguir los consejos de esta respuesta. Si bien resuelve el problema en cuestión, puede causar problemas diferentes en una fecha posterior.

Tengo el mismo problema. Aparentemente, el compilador .NET no se cargó en el GAC. Lo que hice para resolverlo fue:

Primero, en la consola del administrador de paquetes, escriba:

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

Ahora, por alguna razón, los amables caballeros de Microsoft han decidido no instalarlo en el GAC por nosotros. Puede hacerlo manualmente abriendo el Símbolo del sistema del desarrollador y escribiendo:

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

Conclusión

Microsoft trata de alentar a todos a hacer todo con nugets, lo que podría estar bien sin los errores ocasionales con los que te encuentras con el sistema nuget. Intente usar el mismo proyecto en diferentes soluciones, actualice accidentalmente (o no) uno de los muchos nugets que usa en una de ellas, y si no tiene suerte, verá lo que quiero decir cuando intente construir la otra solución. Por otro lado, colocar archivos en el GAC también puede causar problemas en el futuro, ya que las personas tienden a olvidar lo que ponen allí y luego, al configurar nuevos entornos, olvidan incluir estos archivos. Otra posible solución es colocar los archivos en una carpeta central para dlls de terceros (aunque es extraño llamar al compilador como tercero), lo que crea problemas de referencias rotas al configurar nuevos entornos. Si decide instalar el dll en el GAC, Tenga cuidado y recuerde que lo hizo. Si no lo hace, descargue el nuget para cada proyecto nuevamente y cargue con todos los molestos errores causados ​​por él (al menos solía suceder cuando finalmente me cansé de ello y simplemente coloqué los archivos en el GAC). Ambos enfoques pueden causarle dolores de cabeza y crear problemas, es solo una cuestión de qué problemas prefiere tratar. Microsoft recomienda usar el sistema nuget y, en general, es mejor escucharlos que a un programador desconocido en SO, a menos que esté completamente harto del sistema nuget y lo use para tratar con el GAC el tiempo suficiente para que sea una mejor alternativa para ti. descargue el nuget para cada proyecto nuevamente y cargue con todos los molestos errores causados ​​por él (al menos solía suceder cuando finalmente me cansé de él y simplemente coloqué los archivos en el GAC). Ambos enfoques pueden causarle dolores de cabeza y crear problemas, es solo una cuestión de qué problemas prefiere tratar. Microsoft recomienda usar el sistema nuget y, en general, es mejor escucharlos que a un programador desconocido en SO, a menos que esté completamente harto del sistema nuget y lo use para tratar con el GAC el tiempo suficiente para que sea una mejor alternativa para ti. descargue el nuget para cada proyecto nuevamente y cargue con todos los molestos errores causados ​​por él (al menos solía suceder cuando finalmente me cansé de él y simplemente coloqué los archivos en el GAC). Ambos enfoques pueden causarle dolores de cabeza y crear problemas, es solo una cuestión de qué problemas prefiere tratar. Microsoft recomienda usar el sistema nuget y, en general, es mejor escucharlos que a un programador desconocido en SO, a menos que esté completamente harto del sistema nuget y lo use para tratar con el GAC el tiempo suficiente para que sea una mejor alternativa para ti.

Simplemente agregue el siguiente paquete nuget a su proyecto Microsoft.CodeDom.Providers.DotNetCompilerPlatform.

Tuve el mismo problema

Tengo el mismo problema que mi aplicación funcionó en Vs2013 pero recibí el error después de actualizar a Vs2015.

1. En Vs2015, haga clic con el botón derecho en la carpeta Referencias del proyecto para abrir NuGet Package Manager
2. En la pestaña Examinar, busque "DotNetCompilerPlatform" e instale "Microsoft.CodeDom.Providers.DotNetCompilerPlatform" lib

Sé que es un hilo antiguo, pero me gustaría señalar el posible problema de versión de DotNetCompilerPlatform.dll, f. ex. Después de una actualización. Compruebe si el nuevo archivo Web.config generado es diferente a su web.config publicado, en particular la parte system.codedom. En mi caso fue el cambio de versión de 1.0.7 a 1.0.8. El nuevo dll ya se había copiado en el servidor, pero no cambié el antiguo web.config (con algunas configuraciones especiales del servidor):

<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>

Después de actualizar las dos líneas, el error desapareció.

De acuerdo con sus pasos de reproducción, supuse que cambiar la ruta de salida en la propiedad de la aplicación era su único cambio después de crear la aplicación. Lo único que hace este cambio es que le dice a Visual Studio que coloque los ensamblados de salida de MSBuild en la nueva carpeta. Sin embargo, en tiempo de ejecución, ASP.Net no tendría idea de que debería cargar ensamblados desde esta nueva carpeta en lugar de la carpeta \ bin.

Esta respuesta muestra la forma de cambiar el directorio de salida de compilación de una aplicación WebApi. Para obtener exactamente el mismo error que se muestra en esa publicación, debe comentar toda la sección <system.codedom> en web.config. Y luego puede seguir las instrucciones para cambiar la ruta de salida.

Después de obtener su solicitud de trabajo, puede descomentar la sección <system.codedom>. Si no utiliza la nueva sintaxis C # 6 en su aplicación, puede desinstalar Microsoft.CodeDom.Providers.DotNetCompilerPlatform de su aplicación; de lo contrario, puede agregar la siguiente línea de comando en su evento posterior a la compilación,

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

El nuevo proveedor de CodeDom siempre busca la carpeta "\ roslyn" en \ bin. El comando anterior funciona como una solución alternativa y copia la carpeta \ roslyn de su nueva carpeta de salida a \ bin.

Sin embargo, en mis experimentos, la herramienta de publicación de Visual Studio publicó los ensamblajes de salida en la carpeta \ bin en la ubicación de implementación, independientemente de mi configuración de ruta de salida. Supongo que su aplicación aún debería funcionar en la implementación real.

Manera fácil - Proyecto> Administrar paquetes NuGet ...> Examinar (pestaña)> en la entrada de búsqueda configure esto: Microsoft.CodeDom.Providers.DotNetCompilerPlatform

Puede instalar o actualizar o desinstalar e instalar este compilador

Otra posible solución:

Reinicie su instancia de Visual Studio con derechos de administrador

Se detuvo después de publicar en el servidor de producción. La razón por la que me mostró este error se debió a que se desplegó en una sub carpeta. En IIS hice clic derecho en la subcarpeta y ejecuté "Convertir a aplicación" y después de esto funcionó.

En mi caso, esto sucedió cuando cambio el permiso de la carpeta de la aplicación y se eliminó la cuenta IIS_IUSRS. Después de volver a agregar IIS_IUSRS (Administrador IIS-> YourWebApp -> Editar permiso -> Agregar IIS_IUSRS) a la carpeta de la aplicación y funcionó.

Así es como lo resolví :

1. Eliminado el bin carpeta en el directorio del proyecto.
2. Haga clic en Build Solution. En VS2017 (Ejecutar como administrador)> Compilar> Compilar solución .

Si está utilizando git, probablemente esté ignorando el .dll en el commit

Tuve varios proyectos en la solución y el proyecto web (problema al dar este error) no se configuró como proyecto de inicio. Establecí este proyecto web como el proyecto de inicio, hice clic en el elemento del menú "Depurar" -> "Iniciar depuración" y funcionó. Dejé de depurar y luego lo intenté de nuevo y ahora vuelve a funcionar. Extraño.

Entonces el problema volvió. Desinstalé ambos Microsoft.CodeDom.Providers.DotNetCompilerPlatformy Uninstall-package Microsoft.Net.Compilersno ayudé. Luego instalado, sin ayuda. Proyecto limpio y sin ayuda. Reinicié el servidor sin ayuda. Entonces noté que el proyecto no necesitaba el último que actualmente es 1.0.5 sino 1.0.3 ya que ese fue el error que no pudo cargar la versión 1.0.3. Así que instalé esa versión dll y ahora funciona.

ASP.NET no busca bin/debugni ninguna subcarpeta en bin para ensamblajes como lo hacen otros tipos de aplicaciones. Puede indicar al motor de ejecución que busque en un lugar diferente utilizando la siguiente configuración:

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

Debe actualizar los paquetes "Microsoft.CodeDom.Providers.DotNetCompilerPlatform" y "Microsoft.Net.Compilers" en su proyecto.

En mi caso, recibí el error cuando tenía mi aplicación web en 4.5.2 y las bibliotecas de clase referenciadas en 4.6.1. Cuando actualicé la aplicación web a la versión 4.5.2, el error desapareció.

Recibía este error porque mi usuario del grupo de aplicaciones estaba configurado en ApplicationPoolIdentity. Lo cambié a una cuenta de usuario / servicio que tiene acceso a la carpeta y el error desapareció.

Aquí están mis hallazgos. También me enfrenté a este problema hoy por la mañana. Acabo de agregar mi usuario actual al grupo de aplicaciones en el que se estaba ejecutando la aplicación.

Pasos:

1. Abrir IIS

2. Haga clic en el grupo de aplicaciones

3. Seleccione su grupo de aplicaciones en el que está teniendo problemas

4. Haga clic derecho -> configuración avanzada

5. Haga clic en el icono de tres puntos al lado de la identidad

6. Ahora seleccione cuenta personalizada

7. Dé su nombre de usuario y contraseña de PC

8. Salvar

Actualice su aplicación ... y comenzará a funcionar. Hubo algún problema de seguridad para acceder a dll.

simplemente desinstale el paquete de la consola del administrador de paquetes del comando a continuación

PM> Desinstalar paquete Microsoft.CodeDom.Providers.DotNetCompilerPlatform

PM> Desinstalar-paquete Microsoft.Net.Compilers

y luego instalarlo nuevamente desde nuget manager

Si recientemente instaló o actualizó el Microsoft.CodeDom.Providers.DotNetCompilerPlatformpaquete, verifique que las versiones de ese paquete referenciadas en su proyecto apunten a la versión correcta e igual de ese paquete:

• En ProjectName.csproj, asegúrese de que haya una <Import>etiqueta para Microsoft.CodeDom.Providers.DotNetCompilerPlatformy apunte a la versión correcta.

• En ProjectName.csproj, asegúrese de que haya una <Reference>etiqueta para Microsoft.CodeDom.Providers.DotNetCompilerPlatform, y apunte a la versión correcta, tanto en el Includeatributo como en el elemento secundario <HintPath>.

• En ese proyecto web.config, asegúrese de que la <system.codedom>etiqueta esté presente y que sus <compiler>etiquetas secundarias tengan la misma versión en su typeatributo.

Por alguna razón, en mi caso una actualización de este paquete de 1.0.5 a 1.0.8 causado la <Reference>etiqueta en el .csprojque tiene su Includeapuntando a la antigua versión 1.0. 5 .0 (que había eliminado después de actualizar el paquete), pero todo lo demás apuntaba a la nueva y correcta versión 1.0. 8 .0.

¡Asegúrese de que su proyecto se haya construido completamente!

Haga clic en la pestaña 'Salida' y asegúrese de no tener algo como:

========== Reconstruir todo: 14 tuvieron éxito, 1 falló, 0 saltaron =========

Y abre tu bin carpeta y verifique si está actualizada.

Tuve un montón de errores mecanografiados que ignoré al principio, olvidando que estaban rompiendo la compilación y provocando que no se copiaran archivos DLL.

Agregue una referencia al ensamblado CppCodeProvider.

En mi caso, mi proyecto web no se cargó correctamente (mostraba que el proyecto no estaba disponible), luego tuve que volver a cargar mi proyecto web después de abrir mi estudio visual en modo administrador y luego todo funcionó bien.

Simplemente tuve el mismo problema y fue porque moví la ubicación del proyecto y simplemente necesitaba recrear el directorio virtual.

La excepción con la que nos encontramos no estaba en el servidor local sino en el servidor remoto, el CI de Azure lo estaba leyendo desde la carpeta de paquetes pero no se encontraron las versiones del compilador mencionadas anteriormente.

Para solucionar esto, modificamos el archivo del proyecto para que sea algo así

No se hace referencia a ninguno de los paquetes aquí directamente a las variables de entorno.

Esto solucionó el problema, sin embargo, en nuestros casos no utilizamos paquetes directamente desde "package.config", sino que tenemos una carpeta separada para mantener la integridad de la versión entre los equipos.

Vaya a inetmgr desde el comando de inicio En la consola del administrador de IIS, elija la carpeta de la aplicación en Sitio web predeterminado, haga clic derecho en esa carpeta y luego Convierta a la aplicación Ejecute el archivo .asmx Habilitando Se resolvió el problema

Compruebe si la BINcarpeta está cargada por completo o falta en los archivos.

Con respecto a este error, he intentado:

• Limpieza y reconstrucción del proyecto.
• Descarga y recarga del proyecto.
• Modificar el marco de destino
• Modificar la ruta de salida
• Agregar pepitas al GAC
• Eliminar los paquetes uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform uninstall-package Microsoft.Net.Compilerse instalarlos nuevamente.

Si bien todas estas parecen ser soluciones válidas, solo pude generar nuevos errores y al final, el error parece poder mostrarse cuando faltan ciertas referencias / nugets.

En mi caso, recientemente reinstalé Microsoft Office y hacía referencia a ensamblajes como Microsoft.Office.Core. La nueva instalación no parecía incluir los paquetes requeridos, lo que hizo que mi solución no pudiera compilarse correctamente.

Pude resolver este problema volviendo a trabajar mi código hasta el punto en que no necesitaba hacer referencia a Microsoft.Office, pero podría haberlo resuelto buscando los paquetes necesarios e instalándolos en consecuencia.

Parece un mensaje de error poco claro de Visual Studio.

Si ha estado trabajando en un proyecto y esto acaba de aparecer como un error. REINICIAR su computadora (o servidor en mi caso) esto solucionó el problema para mí.