No se pudo encontrar una parte de la ruta … bin \ roslyn \ csc.exe

Estoy intentando ejecutar Asp.net MVC project recuperado del control de fuente TFS. He agregado todas las referencias de ensamblado y puedo comstackr y comstackr correctamente sin ningún error o advertencia.

Pero obtengo el siguiente error en el navegador:

No se pudo encontrar una parte de la ruta ‘C: \ B8akWorkspace \ B8akProject \ B8akSolution \ B8AK.Portal \ bin \ roslyn \ csc.exe’.

Aquí hay una captura de pantalla completa de la página de error.

enter image description here

Después de unos días de investigación, comprendí que Roslyn es una plataforma comstackdora de .NET que ofrece funciones avanzadas de comstackción. Sin embargo, no entiendo por qué mi comstackción está tratando de encontrar \ bin \ roslyn \ csc.exe porque no configuré nada relacionado con Roslyn ni tengo la intención de usar Roslyn en mi proyecto.

El problema con las plantillas predeterminadas de VS2015 es que el comstackdor no se copia realmente en el directorio tfr \ bin \ roslyn \, sino en el directorio {outdir} \ roslyn \

Agregue este código en su archivo .csproj:

       

En mi caso, la solución fue volver a instalar / actualizar los paquetes de Nuget:

  • Microsoft.Net.Compilers 1.1.1
  • Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.1

Luego busqué en .csproj y me aseguré de que las rutas a los paquetes fueran correctas (en mi caso … \ .. \ packages \ *. *) Dentro de las tags en la parte superior y en con el nombre “EnsureNugetPackageBuildImports” en El fondo. Esto está en MVC 5 y .NET Framework 4.5.2.

Respuesta corta: ejecuta esto en la consola del administrador de paquetes:

PM > update-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -r

Su comstackción está tratando de encontrar \bin\roslyn\csc.exe porque se han agregado los siguientes paquetes en su proyecto. Simplemente revise su archivo packages.config , puede tener los dos allí

 Microsoft.CodeDom.Providers.DotNetCompilerPlatform Microsoft.Net.Compilers 

Qué es Roslyn y quién los agregó (paquetes) en el proyecto: si está utilizando .net Framework 4.5.2 para crear proyectos utilizando VS2015, es posible que haya notado que las plantillas de proyecto usan Roslyn de forma predeterminada. En realidad, Roslyn es uno de los comstackdores de código abierto para lenguajes .NET de Microsoft.

¿Por qué deberíamos eliminar a Roslyn: si su proyecto tiene referencias de Roslyn y le interesa implementarlo sin servidor, obtendrá errores no deseados en el sitio web ya que muchos proveedores de hosting todavía no han actualizado sus servidores y por lo tanto no son compatibles con Roslyn. Para resolver esto problema, deberá eliminar el comstackdor de Roslyn de la plantilla del proyecto.

Si no está interesado en usar Roslyn, siga los pasos a continuación para eliminarlo

1. Elimine los paquetes de Nuget, use los siguientes comandos desde Nuget Package Console

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

2. Después de hacer esto, su archivo web.config se debe actualizar automáticamente. En caso de que no lo sea, busque el siguiente código en el archivo web.config y, si lo encuentra, elimine este fragmento de código.

       

Aquí hay una forma más de MSBuild de hacer esto.

        

Pero veo que los archivos roslyn también están en mi directorio bin (no en una carpeta). La aplicación parece funcionar, sin embargo.

¡Una limpieza y reconstrucción funcionó para mí!

Editar: los comentaristas dicen que el paso de limpieza no es necesario. Puedes simplemente reconstruir.

Entonces, la respuesta de Rob Cannon esencialmente funcionó para mí, pero tuve que ajustar algunas de las opciones. Específicamente, tuve que eliminar la condición en el destino, así como cambiar el atributo Incluir, ya que $ CscToolPath estaba vacío cuando el proyecto se estaba construyendo en nuestro servidor de comstackción. Curiosamente, $ CscToolPath NO estaba vacío cuando se ejecuta localmente.

        

Por un comentario de Daniel Neel arriba:

la versión 1.0.3 del paquete Nuget Microsoft.CodeDom.Providers.DotNetCompilerPlatform funciona para mí, pero la versión 1.0.6 causa el error en esta pregunta

La degradación a 1.0.3 resolvió este problema para mí.

Este es un problema conocido con Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.6. La degradación a 1.0.5 me solucionó esto.

En mi caso, solo tenía que ir al directorio bin en Visual Studio Solution Explorer (proyecto de aplicación web) e incluir el proyecto roslyn directamente. Al hacer clic derecho en la carpeta y seleccionar Incluir en proyecto. Y revise la solución nuevamente para activar el proceso de comstackción.

La carpeta roslyn no estaba incluida por defecto.

Abra el archivo de proyecto y elimine todas las referencias con Import Project = “.. \ packages \ Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0 ….

Abra web.config y elimine todos los atributos de los comstackdores de system.codedom

Actualizar los paquetes nuget funcionó para mí Haga clic derecho en la solución> Administrar paquetes NuGet para la solución y actualizar todos los paquetes y especialmente: Microsoft.Net.Compilers y Microsoft.CodeDom.Providers.DotNetCompilerPlatform

Si estaba agregando ASPNETCOMPILER para comstackr sus vistas de Razor en MVC, como en esta pregunta de StackOverflow , cambie PhysicalPath para colocarlo donde se encuentra el paquete de numeración de Roslyn (generalmente apuntado mediante la variable $ CscToolPath ):

   

El problema con las plantillas VS2015 predeterminadas es que el comstackdor no se copia en el {outdir}_PublishedWebsites\tfr\bin\roslyn\ , sino en el {outdir}\roslyn\ . Es probable que esto sea diferente de su entorno local, ya que AppHarbor crea aplicaciones usando un directorio de salida en lugar de construir la solución “en el lugar”.

Para solucionarlo, agregue lo siguiente hacia el final del archivo .csproj justo después del bloque XML ...

   if not exist "$(WebProjectOutputDir)\bin\Roslyn" md "$(WebProjectOutputDir)\bin\Roslyn" start /MIN xcopy /s /y /R "$(OutDir)roslyn\*.*" "$(WebProjectOutputDir)\bin\Roslyn"   

Referencia: https://support.appharbor.com/discussions/problems/78633-cant-build-aspnet-mvc-project-generated-from-vstudio-2015-enterprise

La actualización de Microsoft.CodeDom.Providers.DotNetCompilerPlatform de 1.0.0 a 1.0.1 solucionó esto por mí.

En mi caso, tuve problemas en Jenkins cuando intentó implementarlo en Octopus con el siguiente error:

 MSBUILD : OctoPack error OCT-1676060969: Failed to build the path for '\bin\roslyn\csc.exe' relative to 'T:\workspace\machine.engine\Machine.engine.Test': Invalid URI: The format of the URI could not be determined.. See the inner exception for more details. [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj] MSBUILD : OctoPack error OCT-1676060969: System.Exception: Failed to build the path for '\bin\roslyn\csc.exe' relative to 'T:\workspace\machine.engine\Machine.engine.Test': Invalid URI: The format of the URI could not be determined.. See the inner exception for more details. ---> System.UriFormatException: Invalid URI: The format of the URI could not be determined. [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj] MSBUILD : OctoPack error OCT-1676060969: at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind) [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj] MSBUILD : OctoPack error OCT-1676060969: at System.Uri..ctor(String uriString) [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj] MSBUILD : OctoPack error OCT-1676060969: at OctoPack.Tasks.Util.OctopusPhysicalFileSystem.GetPathRelativeTo(String fullPath, String relativeTo) in Z:\buildAgent\workDir\20ba9f2e0d5e4022\source\OctoPack.Tasks\Util\OctopusPhysicalFileSystem.cs:line 211 [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj] MSBUILD : OctoPack error OCT-1676060969: --- End of inner exception stack trace --- [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj] MSBUILD : OctoPack error OCT-1676060969: at OctoPack.Tasks.Util.OctopusPhysicalFileSystem.GetPathRelativeTo(String fullPath, String relativeTo) in Z:\buildAgent\workDir\20ba9f2e0d5e4022\source\OctoPack.Tasks\Util\OctopusPhysicalFileSystem.cs:line 224 [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj] MSBUILD : OctoPack error OCT-1676060969: at OctoPack.Tasks.CreateOctoPackPackage.AddFiles(XContainer nuSpec, IEnumerable`1 sourceFiles, String sourceBaseDirectory, String targetDirectory, String relativeTo) in Z:\buildAgent\workDir\20ba9f2e0d5e4022\source\OctoPack.Tasks\CreateOctoPackPackage.cs:line 443 [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj] MSBUILD : OctoPack error OCT-1676060969: at OctoPack.Tasks.CreateOctoPackPackage.Execute() in Z:\buildAgent\workDir\20ba9f2e0d5e4022\source\OctoPack.Tasks\CreateOctoPackPackage.cs:line 190 [T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj] Done Building Project "T:\workspace\machine.engine\Machine.engine.Test\Machine.engine.Test.csproj" (default targets) -- FAILED 

Porque

Después de pasar algo de tiempo, estaba usando un componente interno desarrollado que usaba Microsoft.Net.Compilers . La razón por la que el componente interno estaba usando Microsoft.Net.Compilers era para superar este problema ( C #: lanzar comstackción de expresiones no válidas ) y se resolvió de esta manera ( ¿Cómo usar c # 7 con Visual Studio 2015? ). Como resultado, cuando instalé al competente en el progtwig principal, Microsoft.Net.Compilers se agrega automáticamente.

Solución

Mi trabajo fue, desinstalar siguiente de nuestro componente interno por (siguiendo la respuesta @malikKhalil)

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

Y eligió el comstackdor C # 7 en Jenkins en lugar de C # 6 y reconstruye, esto es para asegurar que todo esté funcionando y construyendo correctamente.

Que finalmente en mi progtwig principal intenté actualizar mi componente interno. Y todo que construir de nuevo. Se ha desarrollado sin problemas ni problemas.

enter image description here

Necesita instalar Microsoft.CodeDom.Providers.DotNetCompilerPlatform.BinFix, fue creado especialmente para ese error

En mi caso, similar a Basim, había un paquete NuGet que le decía al comstackdor que necesitábamos C # 6, cosa que no hicimos.

Tuvimos que eliminar el paquete NuGet Microsoft.CodeDom.Providers.DotNetCompilerPlatform que luego se eliminó:

  1. del archivo packages.config

En el nodo system.codedom , puede ver por qué estaba trayendo roslyn: compilerOptions="/langversion:6

Agregue PropertyGroup a su archivo .csproj

   if not exist "$(WebProjectOutputDir)\bin\Roslyn" md "$(WebProjectOutputDir)\bin\Roslyn" start /MIN xcopy /s /y /R "$(OutDir)roslyn\*.*" "$(WebProjectOutputDir)\bin\Roslyn"   

Tuve el mismo problema al instalar mi aplicación en el servidor cuando todo funcionaba perfectamente en localhost.

Ninguna de estas soluciones funcionó, siempre tuve el mismo error:

 Could not find a part of the path 'C:\inetpub\wwwroot\myApp\bin\roslyn\csc.exe' 

Terminé haciendo esto:

  • en mi proyecto de instalación, haga clic derecho, vea> sistema de archivos
  • crear una carpeta bin/roslyn
  • seleccione agregar> archivos y agregue todos los archivos de los packages\Microsoft.Net.Compilers.1.3.2\tools

Esto resolvió mi problema.

También tuve el mismo problema al ejecutar el proyecto. aquí están los pasos que seguí.

  1. Haga clic derecho en la solución
  2. seleccione Solución limpia
  3. Después de que la limpieza tuvo éxito, vuelve a construir tu proyecto
  4. Ejecute el proyecto nuevamente

    Esta vez no vi el mismo error. Esto funciona como se esperaba

Elimine la carpeta Bin en su explorador de soluciones y genere la solución nuevamente. Eso resolvería el problema

Me encontré con este problema después de actualizar algunos paquetes a través de NuGet. Una reconstrucción (en lugar de una versión normal) me ha funcionado.

Tuve el mismo problema después de actualizar DotNetCompilerPlatform. Resuelto reiniciando Visual Studio> Clean Project> Build Project.

mi solución está usando Nuget para actualizar los elementos siguientes a la última versión: – Microsoft.Net.Compilers – Microsoft.CodeDom.Providers.DotNetCompilerPlatform Luego, reconstruí el proyecto. Como mi proyecto es un sitio web, no hay archivo * .csproj. El error anterior aparece cuando bash ver un cshtml en el navegador.

El error se solucionó después de los dos elementos anteriores actualizados a la última versión. Estoy en VS2015 y Windows7 SP1

Tengo un proyecto web sin archivo csproj y las soluciones mencionadas aquí no funcionaron para mí.

Cambiar el marco .NET de destino, reinstalar paquetes ( Update-Package -reinstall ) y luego crear el proyecto funcionó para mí. Incluso puede cambiar el marco de destino después de esta operación (haga que vuelva a instalar los paquetes nuget nuevamente).

Problema

Tenga en cuenta que el NuGet PM rompe el comportamiento de Rosalyn. Haga clic en Tools > NuGet Package Manager > Manage NuGet Packages for Solution Si existe una actualización para Microsoft.CodeDom.Providers.DotNetCompilerPlatform , Microsoft.Net.Compilers o Microsoft.Net.Compilers.netcore , ¡actualícelos y la solución se romperá! Esto ocurre porque las plantillas de Sitios ASP están configuradas para usar versiones específicas en la creación del proyecto. Para ver el problema, haga clic en Mostrar todos los archivos en el Explorador de soluciones.

Fijar

En la creación del proyecto, el $(WebProjectOutputDir)\bin no existe, por lo tanto, cuando NuGet agrega a Rosalyn como una dependencia, lo instala correctamente. Después de actualizar los paquetes de soluciones, el directorio $(WebProjectOutputDir)\bin ve así:

$(WebProjectOutputDir)\bin\bin\rosalyn

La solución más sencilla es cortar y pegar rosalyn en la ubicación correcta, y luego eliminar la carpeta bin extra. Ahora puede actualizar la página y el sitio se cargará.

Tuve que cambiar los archivos del proyecto WebAPI y MVC para no crear vistas:

 false 

Esto resolvió el error de servidor TFS 2015 Build con roslyn. Todavía no estoy seguro de por qué se copió csc.exe en \ bin \ csc.exe, pero el proceso de publicación estaba buscando \ bin \ Roslyn \ csc.exe … no se pudo encontrar la transformación que causaba esa discrepancia.

Experimenté este error en un servidor de comstackción de Jenkins que ejecuta MSBuild, que genera los archivos de comstackción en una ubicación de carpeta separada (_PublishedWebsites). Exactamente lo mismo: la carpeta roslyn no estaba en el directorio bin, y todos los archivos roslyn estaban agrupados con los archivos bin.

La respuesta de @ igor-semin fue lo único que funcionó para mí (ya que estoy usando las características del lenguaje C # 6, no puedo simplemente desinstalar los paquetes nuget según otras respuestas), pero como también estoy ejecutando CodeAnalysis, estaba obteniendo otro error en mi servidor de destino de despliegue:

Se detectó un bash de anular una asignación existente para el tipo Microsoft.CodeAnalysis.IComstacktionUnitSyntax con el nombre “”, actualmente asignado para escribir Microsoft.CodeAnalysis.CSharp.Syntax.ComstacktionUnitSyntax, para escribir Microsoft.CodeAnalysis.VisualBasic.Syntax.ComstacktionUnitSyntax.

La razón de esto es que como los archivos roslyn se están volcando en el directorio bin principal, cuando ejecuta el xcopy para volver a crearlos en la carpeta roslyn anidada, ahora tiene comstackdas 2 copias de estos archivos y hay un conflicto entre ellos . Después de mucha frustración, decidí una solución ‘hack’: una tarea posterior a la comstackción para eliminar estos archivos del directorio bin, eliminando el conflicto.

El .csproj de mis proyectos ofensivos ahora se ve así:

………………. más aquí ………………….

    if not exist "$(WebProjectOutputDir)\bin\Roslyn" md "$(WebProjectOutputDir)\bin\Roslyn" start /MIN xcopy /s /y /R "$(OutDir)roslyn\*.*" "$(WebProjectOutputDir)\bin\Roslyn"          

………………. más aquí ………………….

Me encontré con este problema con la canalización de publicación (que produce un directorio _PublishedWebsites), y lo usé como un objective en el proyecto:

    

El inconveniente es que habrá dos copias de los archivos de Roslyn en la salida.

Tuve este error después de cambiar el nombre de una solución y algunos proyectos incluidos, y jugar con la eliminación de paquetes nuget. Comparé el nuevo proyecto con el último proyecto de trabajo, y encontré que faltaban las siguientes líneas y era necesario volver a agregarlas:

     

Al hacerlo, resolvió el problema para mí.