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

Estoy tratando de ejecutar el proyecto Asp.net MVC recuperado del control de origen TFS. He agregado todas las referencias de ensamblaje y puedo compilar y compilar correctamente sin ningún error o advertencia.

Pero me sale 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.

Después de unos días de investigación, entendí que Roslyn es una plataforma compiladora .Net que ofrece funciones avanzadas de compilación. Sin embargo, no entiendo por qué mi compilació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 VS2015 predeterminadas es que el compilador en realidad no se copia en el directorio tfr \ bin \ roslyn \, sino más bien en el directorio {outdir} \ roslyn \

Agregue este código en su archivo .csproj:

<Target Name="CopyRoslynFiles" AfterTargets="AfterBuild" Condition="!$(Disable_CopyWebApplication) And '$(OutDir)' != '$(OutputPath)'">
    <ItemGroup>
      <RoslynFiles Include="$(CscToolPath)\*" />
    </ItemGroup>
    <MakeDir Directories="$(WebProjectOutputDir)\bin\roslyn" />
    <Copy SourceFiles="@(RoslynFiles)" DestinationFolder="$(WebProjectOutputDir)\bin\roslyn" SkipUnchangedFiles="true" Retries="$(CopyRetryCount)" RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)" />
</Target>

TL; DR

ejecutar esto en la consola del Administrador de paquetes:

Update-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -r

Más información

Este problema no está relacionado con Visual Studio en sí, por lo que las respuestas que sugieren agregar pasos de compilación para copiar archivos son más bien una solución alternativa. Lo mismo con agregar binarios del compilador manualmente al proyecto.

El compilador de Roslyn proviene de un paquete NuGet y hay / hubo un error en algunas versiones de ese paquete (no sé exactamente cuáles). La solución es reinstalar / actualizar ese paquete a una versión libre de errores. Originalmente antes de escribir la respuesta en 2015, la arreglé instalando los siguientes paquetes en versiones específicas:

• 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 sean correctas (en mi caso ... \ .. \ packages \ *. *) Dentro de las etiquetas <ImportProject>en la parte superior y <Target>con el nombre "GuaranteeNuGetPackageBuildImports" en la parte inferior. Esto está en MVC 5 y .NET Framework 4.5.2.

Su compilación está intentando encontrar \bin\roslyn\csc.exeporque se han agregado los siguientes paquetes a su proyecto. Solo revise su packages.configarchivo, puede tener ambos allí

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

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

¿Por qué deberíamos eliminar Roslyn? Si su proyecto tiene referencias de Roslyn y está interesado en implementarlo sin servidor, obtendrá 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.

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

1. Elimine los paquetes NuGet, use los siguientes comandos de la Consola de paquetes Nuget

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

2. Después de hacer esto, su archivo web.config debería actualizarse automáticamente. En caso de que no sea así, busque el siguiente código en el web.configarchivo y, si lo encuentra, elimine este fragmento de código.

<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>
      <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+"></compiler>
    </compilers>
</system.codedom>

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

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

<Target Name="CopyRoslynFiles" AfterTargets="AfterBuild" Condition="!$(Disable_CopyWebApplication) And '$(OutDir)' != '$(OutputPath)'">
    <ItemGroup>
      <RoslynFiles Include="$(CscToolPath)\*" />
    </ItemGroup>
    <MakeDir Directories="$(WebProjectOutputDir)\bin\roslyn" />
    <Copy SourceFiles="@(RoslynFiles)" DestinationFolder="$(WebProjectOutputDir)\bin\roslyn" SkipUnchangedFiles="true" Retries="$(CopyRetryCount)" RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)" />
</Target>

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

Como se señaló en un problema en el proyecto Roslyn en GitHub , una solución (que funcionó para mí) es simplemente descargar y volver a cargar el proyecto en Visual Studio.

La carpeta "bin \ roslyn" no se creó en la compilación o reconstrucción hasta que volví a cargar el proyecto.

Seguí estos pasos y funcionó perfectamente

• Eliminar todas las carpetas bin y obj
• Solución limpia y reconstrucción
• Ejecute este comando en powershell

Update-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -r

Después de probar todas las soluciones sin cigarro, lo arreglé actualizando este paquete Nuget en Visual Studios:

Microsoft.CodeDom.Providers.DotNetCompilerPlatform

El mío fue de 1.0.0 a 2.0.0 como referencia (el error ya no se muestra)

1. Solución limpia
2. Reconstruir solución, estos dos pasos funcionaron para mí.

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

• Haga clic derecho en su proyecto y seleccione Administrar paquetes Nuget
• Busque "Microsoft.CodeDom.Providers.DotNetCompilerPlatform"
• Simplemente actualice a una versión anterior o anterior (no importa cuál), y luego actualice nuevamente a su versión original.

Esto reinstala todas las dependencias y archivos del paquete (como csc.exe)

Entonces, la respuesta de Rob Cannon esencialmente funcionó para mí, pero tuve que ajustar algunas 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 compilación. Curiosamente, $ CscToolPath NO estaba vacío cuando se ejecutaba localmente.

<Target Name="CopyRoslynFiles" AfterTargets="AfterBuild" >
  <ItemGroup>
    <RoslynFiles Include="$(SolutionDir)packages\Microsoft.Net.Compilers.1.1.1\tools\*" />
  </ItemGroup>
  <MakeDir Directories="$(WebProjectOutputDir)\bin\roslyn" />
  <Copy SourceFiles="@(RoslynFiles)" DestinationFolder="$(WebProjectOutputDir)\bin\roslyn" SkipUnchangedFiles="true" Retries="$(CopyRetryCount)" RetryDelayMilliseconds="$(CopyRetryDelayMilliseconds)" />
</Target>

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

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

Para VS 2019, elimine completamente el siguiente nodo:

<system.codedom>
</system.codedom>

Por un comentario de Daniel Neel arriba:

la versión 1.0.3 del paquete Microsoft.CodeDom.Providers.DotNetCompilerPlatform Nuget 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í.

En mi caso, tuve un problema en Jenkins cuando trató de 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 un tiempo, estaba usando un componente interno desarrollado que estaba usando Microsoft.Net.Compilers. La razón por la que el componente interno estaba usando Microsoft.Net.Compilersera para superar este problema ( C #: arrojar una compilación de expresión no válida ) y se resolvió de esta manera ( ¿Cómo usar C # 7 con Visual Studio 2015? ). Esto da como resultado que, cuando instalé el componente en el programa principal, Microsoft.Net.Compilersse agregó automáticamente.

Solución

Mi solución fue desinstalar el seguimiento de nuestro componente interno (siguiendo la respuesta de @malikKhalil)

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

Y eligió el compilador C # 7 en Jenkins en lugar de C # 6 y reconstruir, esto es para garantizar que todo funcione y se compile correctamente.

Finalmente, en mi programa principal intenté actualizar mi componente interno. Y todo que construir de nuevo. Se ha construido sin problemas ni problemas.

En mi caso, solo necesitaba 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 el proyecto. Y vuelva a comprobar la solución para activar el proceso de compilación.

La carpeta roslyn no se incluyó por defecto.

También estaba teniendo el mismo problema mientras ejecutaba 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 la limpieza exitosa, construya nuevamente su proyecto
4. Ejecute el proyecto nuevamente

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

La actualización Microsoft.CodeDom.Providers.DotNetCompilerPlatformde 1.0.0 a 1.0.1 solucionó esto para mí.

Abra el archivo del 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 compiladores system.codedom

Como ya se ha señalado por /programming/32780315#34391473 , la solución rápida es utilizar el gestor de paquetes, Tools> Nuget Package Manager> Package Manager Console, para funcionar

Update-Package Microsoft.CodeDom.Providers.DotNetCompilerPlatform -r

Pero una solución alternativa (que recrea de forma automática y silenciosa sus paquetes si faltan) es eliminar un atributo del Web.configarchivo de su proyecto .
( Web.configestá en el mismo directorio que su.csproj archivo).

Abra el Web.configarchivo en un editor de texto (o dentro de Visual Studio).
- En la etiqueta configuration> system.codedom> compilers> compiler language="c#;cs;csharp", eliminar completamente el typeatributo.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <!-- ... -->
  <system.codedom>
    <compilers>
      <compiler language="c#;cs;csharp" extension=".cs"
        type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=1.0.5.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.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
        warningLevel="4" compilerOptions="/langversion:default /nowarn:41008 /define:_MYTYPE=\&quot;Web\&quot; /optionInfer+"/>
    </compilers>
  </system.codedom>
</configuration>

En resumen, elimine la línea que comienza con type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.

(Presumiblemente, la misma solución funciona tanto para Visual Basic como para Csharp, pero no lo he probado).

Visual Studio se encargará del resto. No más Server Error in '/' Application.

En el código de ejemplo que proporcioné en el archivo zip anterior, ahora obtendrá HTTP Error 403 cuando presione Ctrl+ F5.

Intente reemplazar http://localhost:64195en su navegador web con http://localhost:64195/api/products.
La API web ahora se muestra como debería:

Como provocación, intenté eliminar todo el packagedirectorio de mi solución de Visual Studio.
Se recreó automática y silenciosamente tan pronto como la (re) construí.

Por último, pero no menos importante, aquí hay un código que reproduce el error: http://schulze.000webhostapp.com/vs/SrvrErr-reproduce.zip (Originalmente de https://github.com/aspnet/AspNetDocs/tree/master/aspnet / web-api / overview / advanced / calling-a-web-api-from-a-net-client / sample / server / ProductsApp )

En mi caso, simplemente eliminar todo dentro de la carpeta bin y volver a compilar hizo todo el trabajo por mí.

Si estaba agregando ASPNETCOMPILER para compilar sus vistas de Razor en MVC, como en esta pregunta de StackOverflow , entonces cambie PhysicalPath para colocar donde se encuentra el paquete Nuget de Roslyn (generalmente señalado a través de la variable $ CscToolPath ):

<Target Name="AfterBuild" Condition="'$(MvcBuildViews)'=='true'">
<AspNetCompiler VirtualPath="temp" PhysicalPath="$(CscToolPath)" />

El problema con las plantillas VS2015 predeterminadas es que el compilador en realidad no se copia en el {outdir}_PublishedWebsites\tfr\bin\roslyn\directorio, sino en el {outdir}\roslyn\directorio. Es probable que esto sea diferente de su entorno local, ya que AppHarborcrea aplicaciones utilizando un directorio de salida en lugar de crear la solución "en el lugar".

Para solucionarlo, agregue lo siguiente hacia el final del .csprojarchivo justo después del bloque xml<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">...</Target>

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

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

En mi caso, similar a Basim, había un paquete NuGet que le decía al compilador que necesitábamos C # 6, lo cual no era necesario.

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

1. <package id="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" version="1.0.0" targetFramework="net452" /> desde el archivo packages.config
2. <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> </system.codedom>

En el system.codedomnodo, puede ver por qué traía a Roslyn:compilerOptions="/langversion:6

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

Tuve el mismo problema al instalar mi aplicación en el servidor cuando todo funcionó 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 configuración, haga clic derecho, ver> sistema de archivos
• crear una bin/roslyncarpeta
• seleccione agregar> archivos y agregue todos los archivos de packages\Microsoft.Net.Compilers.1.3.2\tools

Esto resolvió mi problema.

Reiniciar Windows

Esta es la única solución que me funcionó después de intentar reconstruir, eliminar contenido biny reconstruir, reiniciar Visual Studio.

Es otro ejemplo de cuán terribles son las herramientas de compilación de C # / .NET.

Creo que (después de leer muchas de las respuestas), la conclusión general es que la causa y la solución de este problema depende en gran medida de la configuración y el proyecto, por lo que si una respuesta no funciona, intente con otra. Pruebe primero soluciones no intrusivas / destructivas, como reiniciar Visual Studio, reiniciar, reconstruir, etc., PRIMERO, antes de meterse con paquetes NuGet o reinstalar herramientas de desarrollo. ¡Buena suerte!

(NOTA: Usando Visual Studio 2019, y el archivo del proyecto fue creado originalmente en Visual Studio 2015. Quizás esto ayude a alguien a investigar el problema)

(EDITAR: ¿Podría esto ser causado por no reiniciar después de instalar / modificar la instalación de Visual Studio o actualizar Visual Studio cuando el instalador solicita reiniciar?)

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

Cambiar el framework .NET de destino, reinstalar paquetes ( Update-Package -reinstall) y luego construir el proyecto funcionó para mí. Incluso puede volver a cambiar el marco de destino después de esta operación (asegúrese de reinstalar nuevamente los paquetes nuget).