c# - example - No se pudo encontrar el tipo de proveedor CodeDom "Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider"

web api rest c# tutorial (29)

Es un proyecto de WebApi que usa VS2015.

Paso para reproducir:

Crear un proyecto WebApi vacío
Cambie la ruta de salida de Build de "bin /" a "bin / Debug /"
correr

Todo funciona perfectamente hasta que cambie la ruta de compilación de salida 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.

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 cual podría estar bien sin los errores ocasionales con los que se topa 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.

¡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 abra su carpeta bin 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.

ASP.NET no busca en bin/debug o en 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>

Agregue una referencia al ensamblado CppCodeProvider.

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:

Abrir IIS
Haga clic en el grupo de aplicaciones
Seleccione su grupo de aplicaciones en el que está teniendo problemas
Haga clic derecho -> configuración avanzada
Haga clic en el icono de tres puntos al lado de la identidad
Ahora seleccione cuenta personalizada
Dé su nombre de usuario y contraseña de PC
Salvar

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

Así es como lo resolví :

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

Asegúrese de que Internet Information Services (IIS) esté habilitado en las funciones de Windows en su máquina.

Compruebe si la carpeta BIN 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
Eliminando los paquetes uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform uninstall-package Microsoft.Net.Compilers e instalándolos 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 modificando 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.

De acuerdo con sus pasos de repro, 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 answer 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, es posible que desee 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 la configuración de la ruta de salida. Supongo que su aplicación aún debería funcionar en la implementación real.

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

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

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.

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

Entonces el problema volvió. Desinstalé Microsoft.CodeDom.Providers.DotNetCompilerPlatform y Uninstall-package Microsoft.Net.Compilers pero no obtuve ayuda. 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.

La excepción con la que nos encontramos no fue 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 usamos paquetes directamente desde "package.config", sino que tenemos una carpeta separada para mantener la integridad de la versión entre los equipos.

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

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

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

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

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

Si recientemente instaló o actualizó el paquete Microsoft.CodeDom.Providers.DotNetCompilerPlatform , 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 una etiqueta <Import> para Microsoft.CodeDom.Providers.DotNetCompilerPlatform esté presente y apunte a la versión correcta.
En ProjectName.csproj , asegúrese de que esté presente una etiqueta <Reference> para Microsoft.CodeDom.Providers.DotNetCompilerPlatform , y apunte a la versión correcta, tanto en el atributo Include como en el elemento secundario <HintPath> .
En el proyecto web.config ese proyecto, asegúrese de que la etiqueta <system.codedom> esté presente y que sus etiquetas secundarias <compiler> tengan la misma versión en su atributo type .

Por alguna razón, en mi caso, una actualización de este paquete de 1.0.5 a 1.0.8 provocó que la etiqueta <Reference> en el .csproj tuviera su Include apuntando a la versión anterior 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.

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 para otros proyectos (C # 4.5.2) en los que trabajé.

Haz los siguientes pasos:

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
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=/"Web/" /optionInfer+" /> </compilers>

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

Tuve el mismo problema

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

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

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

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.

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 con el botón derecho en esa carpeta y luego Convierta a la aplicación Ejecute el archivo .asmx Habilitando Se resolvió el problema

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

Otra posible solución:

¡Reinicie su instancia de Visual Studio con derechos de administrador !