Não foi possível encontrar uma parte do caminho… bin \ roslyn \ csc.exe

Estou tentando executar o projeto asp.net MVC recuperado do controle de origem TFS. Adicionei todas as referências de montagem e sou capaz de criar e compilar com êxito sem nenhum erro ou aviso.

Mas eu recebo o seguinte erro no navegador:

Não foi possível encontrar uma parte do caminho 'C: \ B8akWorkspace \ B8akProject \ B8akSolution \ B8AK.Portal \ bin \ roslyn \ csc.exe'.

Aqui está uma captura de tela completa da página de erro.

Após alguns dias de pesquisa, entendi que Roslyn é a plataforma de compilador .Net que oferece recursos avançados de compilação. No entanto, não entendo por que minha compilação está tentando encontrar \ bin \ roslyn \ csc.exe porque não configurei nada relacionado a Roslyn e não pretendo usá-lo em meu projeto.

O problema com os modelos padrão do VS2015 é que o compilador não é realmente copiado para o diretório tfr \ bin \ roslyn \, mas para o diretório {outdir} \ roslyn \

Adicione este código no seu arquivo .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

execute isso no Package Manager Console:

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

Mais Informações

Esse problema não está relacionado ao próprio Visual Studio, portanto, as respostas sugerindo a adição de etapas de compilação para copiar arquivos são uma solução alternativa. O mesmo ocorre com a adição manual de binários do compilador ao projeto.

O compilador Roslyn vem de um pacote NuGet e há / houve um bug em algumas versões desse pacote (não sei exatamente quais). A solução é reinstalar / atualizar esse pacote para uma versão livre de erros. Originalmente, antes de escrever a resposta em 2015, eu a corrigi instalando os seguintes pacotes em versões específicas:

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

Depois, procurei no .csproj e verifiquei se os caminhos para os pacotes estão corretos (no meu caso .. \ .. \ packages \ *. *) Dentro das tags <ImportProject>na parte superior e <Target>com o nome "GuaranteNuGetPackageBuildImports" na parte inferior. Isso está no MVC 5 e no .NET Framework 4.5.2.

Sua compilação está tentando encontrar \bin\roslyn\csc.exeporque os seguintes pacotes foram adicionados ao seu projeto. Basta revisar seu packages.configarquivo, você pode ter os dois lá

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

O que é Roslyn e Quem os adicionou (pacotes) no projeto: Se você estiver usando o .net Framework 4.5.2 para criar projetos usando o VS2015, talvez tenha notado que os modelos de projeto usam o Roslyn por padrão. Na verdade, Roslyn é um dos compiladores de código aberto para linguagens .NET da Microsoft.

Por que devemos excluir o Roslyn: se o seu projeto tem referências ao Roslyn e você está interessado em implantá-lo em nenhum servidor, você receberá erros indesejados no site, pois muitos provedores de hospedagem ainda não fizeram o upgrade dos servidores e, portanto, não oferecem suporte ao Roslyn. Para resolver esse problema, você precisará remover o compilador Roslyn do modelo de projeto.

se você não estiver interessado em usar o Roslyn, siga as etapas abaixo para excluí-lo

1. Remova os pacotes NuGet, use os seguintes comandos do Nuget Package Console

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

2. Depois de fazer isso, seu arquivo web.config deve ser atualizado automaticamente. Caso contrário, procure o código abaixo no web.configarquivo e, se for encontrado, exclua este trecho 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>

Uma limpeza e reconstrução funcionou para mim!

Aqui está uma maneira mais MSBuild de fazer isso.

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

Mas percebo que os arquivos roslyn também estão no meu diretório bin (não em uma pasta). O aplicativo parece funcionar, no entanto.

Conforme observado em um problema no projeto Roslyn no GitHub , uma solução (que funcionou para mim) é simplesmente descarregar e recarregar o projeto no Visual Studio.

A pasta "bin \ roslyn" não foi criada na construção ou reconstrução até eu recarregar o projeto.

Eu segui esses passos e funcionou perfeitamente

• Exclua todas as pastas bin e obj
• Solução limpa e reconstrução
• Execute este comando no PowerShell

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

Depois de tentar todas as correções sem charuto, eu a corrigi atualizando este pacote Nuget no Visual Studios:

Microsoft.CodeDom.Providers.DotNetCompilerPlatform

O meu foi de 1.0.0 a 2.0.0 para referência (o erro não aparece mais)

1. Solução Limpa
2. Solução de reconstrução, essas duas etapas funcionaram para mim.

Você precisa instalar o Microsoft.CodeDom.Providers.DotNetCompilerPlatform.BinFix, foi criado especialmente para esse erro

• Clique com o botão direito do mouse no seu projeto e selecione Gerenciar Pacotes de Nuget
• Encontre "Microsoft.CodeDom.Providers.DotNetCompilerPlatform"
• Simplesmente atualize para uma versão mais antiga ou mais recente (não importa qual) e, em seguida, atualize novamente para a versão original.

Isso reinstala todas as dependências e arquivos do pacote (como csc.exe)

Portanto, a resposta de Rob Cannon funcionou essencialmente para mim, mas tive que ajustar algumas das opções. Especificamente, tive que remover a condição no destino e alterar o atributo Incluir, pois $ CscToolPath estava vazio quando o projeto estava sendo construído em nosso servidor de compilação. Curiosamente, $ CscToolPath NÃO estava vazio ao executar 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>

Atualizar pacotes de nuget funcionou para mim Clique com o botão direito do mouse na solução> Gerenciar pacotes do NuGet para solução e atualize todos os pacotes e, especialmente: Microsoft.Net.Compilers e Microsoft.CodeDom.Providers.DotNetCompilerPlatform

Este é um problema conhecido no Microsoft.CodeDom.Providers.DotNetCompilerPlatform 1.0.6. O downgrade para 1.0.5 corrigiu isso para mim.

Para o VS 2019, remova completamente o seguinte nó:

<system.codedom>
</system.codedom>

Por um comentário de Daniel Neel acima:

versão 1.0.3 do pacote Microsoft.CodeDom.Providers.DotNetCompilerPlatform Nuget funciona para mim, mas a versão 1.0.6 causa o erro nesta pergunta

A atualização para a versão 1.0.3 resolveu esse problema para mim.

No meu caso, tive um problema no Jenkins ao tentar implantá-lo no Octopus com o seguinte erro:

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

Causa

Depois de passar algum tempo, eu estava usando um componente interno desenvolvido que estava usando Microsoft.Net.Compilers. O motivo pelo qual o componente interno estava usando Microsoft.Net.Compilersera solucionar esse problema ( C #: lançar compilação de expressão inválida ) e foi resolvido dessa maneira ( como usar o C # 7 com o Visual Studio 2015? ). Esse resultado, quando instalei o componente no programa principal, Microsoft.Net.Compilersfoi adicionado automaticamente.

Solução

Minha solução foi desinstalar a seguir do nosso componente interno por (seguindo a resposta @malikKhalil)

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

E escolheu o compilador C # 7 no Jenkins em vez do C # 6 e reconstrua, para garantir que tudo esteja funcionando e construindo corretamente.

Finalmente, no meu programa principal, tentei atualizar meu componente interno. E tudo o que construir novamente. Foi construído sem problemas ou questões.

No meu caso, eu só precisava ir para o diretório bin no Visual Studio Solution Explorer (projeto de aplicativo da web) e incluir o projeto roslyn diretamente. Clicando com o botão direito do mouse na pasta e selecionando Incluir no Projeto. E verifique novamente a solução para acionar o processo de compilação.

A pasta roslyn não foi incluída por padrão.

Eu também estava tendo o mesmo problema ao executar o projeto. Aqui estão os passos que eu segui.

1. Clique com o botão direito na solução
2. selecione Solução limpa
3. Após a limpeza bem-sucedida, Construa novamente seu projeto
4. Execute o projeto novamente

Desta vez, não vi o mesmo erro. Isso funciona como esperado.

A atualização Microsoft.CodeDom.Providers.DotNetCompilerPlatformda 1.0.0 para a 1.0.1 corrigiu isso para mim.

Abra o arquivo do projeto e remova todas as referências com Import Project = ".. \ packages \ Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0 ....

Abra o web.config e remova todos os atributos dos compiladores system.codedom

Como já foi observado por /programming/32780315#34391473 , a correção rápida é usar o gerenciador de pacotes, Tools> Nuget Package Manager> Package Manager Console, para executar

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

Mas uma solução alternativa (que automaticamente e silenciosamente recria seus pacotes, se estiverem ausentes) é remover um atributo do Web.configarquivo do seu projeto .
( Web.configestá no mesmo diretório que o seu .csprojarquivo.)

Abra o Web.configarquivo em um editor de texto (ou dentro do Visual Studio).
- Na tag configuration> system.codedom> compilers> compiler language="c#;cs;csharp", remover completamente o 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>

Em resumo, remova a linha que começa com type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.

(Presumivelmente, a mesma correção funciona para o Visual Basic e para o Csharp, mas eu não tentei.)

O Visual Studio cuidará do resto. Não mais Server Error in '/' Application.

No código de exemplo que forneci no arquivo zip acima, você receberá agora HTTP Error 403 quando pressionar Ctrl+ F5.

Tente substituir http://localhost:64195no seu navegador por http://localhost:64195/api/products.
A API da web agora é exibida como deveria:

Como provocação, tentei remover o packagediretório inteiro da minha solução do Visual Studio.
Ele foi recriado automaticamente e silenciosamente assim que eu (re) o construí.

Por último, mas não menos importante, eis o código que reproduz o erro: http://schulze.000webhostapp.com/vs/SrvrErr-reproduce.zip (Originalmente em https://github.com/aspnet/AspNetDocs/tree/master/aspnet / web-api / overview / advanced / chamando-a-web-api-de-um-net-client / sample / server / ProductsApp )

No meu caso, apenas excluir tudo dentro da pasta bin e recompilar fez todo o trabalho para mim.

Se você estava adicionando o ASPNETCOMPILER para compilar suas visualizações do Razor no MVC, como nesta pergunta do StackOverflow , altere o PhysicalPath para o local onde o pacote de nuget do Roslyn está localizado (geralmente apontado pela variável $ CscToolPath ):

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

O problema com os modelos padrão do VS2015 é que o compilador não é realmente copiado para o {outdir}_PublishedWebsites\tfr\bin\roslyn\diretório, mas para o {outdir}\roslyn\diretório. Provavelmente, isso é diferente do ambiente local, pois AppHarborcria aplicativos usando um diretório de saída em vez de criar a solução "no local".

Para corrigi-lo, adicione o seguinte no final do .csprojarquivo, logo após o bloco 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>

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

No meu caso, semelhante ao Basim, havia um pacote NuGet que dizia ao compilador que precisávamos do C # 6, o que não era necessário.

Tivemos que remover o pacote NuGet, Microsoft.CodeDom.Providers.DotNetCompilerPlatformque foi removido:

1. <package id="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" version="1.0.0" targetFramework="net452" /> do arquivo 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>

No system.codedomnó, você pode ver por que estava trazendo roslyn:compilerOptions="/langversion:6

Exclua a pasta Bin no seu gerenciador de soluções e crie a solução novamente. Isso resolveria o problema

Eu tive o mesmo problema ao instalar meu aplicativo no servidor quando tudo funcionou perfeitamente no localhost.

Nenhuma dessas soluções funcionou, eu sempre tive o mesmo erro:

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

Acabei fazendo isso:

• no meu projeto de instalação, clique com o botão direito, veja> sistema de arquivos
• crie uma bin/roslynpasta
• selecione adicionar> arquivos e adicione todos os arquivos de packages\Microsoft.Net.Compilers.1.3.2\tools

Isso resolveu meu problema.

Reinicie o Windows.

Esta é a única solução que funcionou para mim depois de tentar reconstruir, excluir o conteúdo bine reconstruir, reiniciar o Visual Studio.

É mais um exemplo de quão terrível são as ferramentas de compilação C # / .NET.

Acho que (depois de ler muitas das respostas), a conclusão geral é que a causa e a solução desse problema dependem muito da configuração e do projeto; portanto, se uma resposta não funcionar, tente outra. Tente soluções não-intrusivas / destrutivas, como reiniciar o Visual Studio, reiniciar, reconstruir etc. PRIMEIRO, antes de mexer nos pacotes NuGet ou reinstalar as ferramentas de desenvolvimento. Boa sorte!

(NOTA: usando o Visual Studio 2019, e o arquivo do projeto foi criado originalmente no Visual Studio 2015. Talvez isso ajude alguém a investigar o problema)

(EDIT: isso pode ser causado por não reiniciar depois de instalar / modificar a instalação do Visual Studio ou atualizar o Visual Studio quando o instalador solicitar a reinicialização?)

Eu tenho um projeto web sem o arquivo csproj e as soluções mencionadas aqui não funcionaram para mim.

Alterar a estrutura .NET de destino, reinstalar packages ( Update-Package -reinstall) e criar o projeto funcionaram para mim. Você pode até mudar a estrutura de destino novamente após esta operação (depois de reinstalar os pacotes nuget novamente depois).