O tipo de provedor CodeDom "Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider" não pôde ser localizado

É um projeto WebApi usando o VS2015.

Etapa para reproduzir:

1. Crie um projeto WebApi vazio
2. Altere o caminho de saída Build de "bin \" para "bin \ Debug \"
3. Corre

Tudo está funcionando perfeitamente até que eu mudei o caminho Build Output de "bin \" para "bin \ Debug \" De fato, qualquer caminho de saída que não seja "bin \" não funcionará.

Uma pequena coisa adicional é que, ter outro caminho de saída para qualquer lugar funcionaria desde que eu deixasse uma compilação em "bin \".

Por favor, ajude a fornecer a solução para resolver isso. Eu acho que isso custará um problema na implantação real.

Se o seu projeto tiver referências ao Roslyn e você o estiver implantando em um servidor IIS , poderá ocorrer erros indesejados no site, pois muitos provedores de hospedagem ainda não atualizaram seus servidores e, portanto, não são compatíveis com o Roslyn.

Para resolver esse problema, você precisará remover o compilador Roslyn do modelo de projeto . A remoção do Roslyn não deve afetar a funcionalidade do seu código. Funcionou bem para mim e para outros projetos (C # 4.5.2) nos quais trabalhei.

Execute os seguintes passos:

1. Remova dos seguintes pacotes Nuget usando a linha de comando mostrada abaixo ( ou você pode usar a GUI do gerenciador de pacotes Nuget clicando com o botão direito do mouse em Root Project Solution e removendo-os ).

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

2. Remova o seguinte código do seu arquivo Web.Config e reinicie o IIS . ( Use esse método apenas se a etapa 1 não resolver o seu 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>

Cuidado ao seguir os conselhos desta resposta. Embora resolva o problema em questão, pode causar problemas diferentes posteriormente.

Eu tenho o mesmo problema. Aparentemente, o compilador .NET não foi carregado no GAC. O que eu fiz para resolver isso foi:

Primeiro, no console do gerenciador de pacotes, digite:

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

Agora, por algum motivo, os bons cavalheiros da Microsoft decidiram não instalá-lo no GAC para nós. Você pode fazer isso manualmente, abrindo o prompt de comando do desenvolvedor e digitando:

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

Conclusão

A Microsoft tenta incentivar todos a fazer tudo com pepitas, o que pode ser bom sem os erros ocasionais nos quais você se depara com o sistema de pepitas. Tente usar o mesmo projeto em soluções diferentes, atualize acidentalmente (ou não) um dos muitos nugets que ele usa em um deles e, se você tiver azar, verá o que quero dizer quando tentar criar a outra solução. Por outro lado, colocar arquivos no GAC também pode causar problemas futuros, pois as pessoas tendem a esquecer o que colocam lá e, ao configurar novos ambientes, esquecem de incluir esses arquivos. Outra solução possível é colocar os arquivos em uma pasta central para DLLs de terceiros (mesmo que seja estranho chamar o compilador como terceiro), o que cria problemas de referências quebradas ao configurar novos ambientes. Se você decidir instalar a dll no GAC, tenha cuidado e lembre-se de que fez isso. Caso contrário, baixe o nuget de cada projeto novamente e aguarde todos os bugs irritantes causados ​​por ele (pelo menos costumava acontecer quando eu finalmente me cansava dele e apenas colocava os arquivos no GAC). Ambas as abordagens podem causar dores de cabeça e criar problemas; é apenas uma questão de quais problemas você prefere lidar. A Microsoft recomenda usar o sistema de pepitas e, geralmente, é melhor ouvi-los do que um programador desconhecido no SO, a menos que você esteja completamente cansado do sistema de pepitas e que lide com o GAC por tempo suficiente para que seja uma alternativa melhor. para voce. faça o download do nuget de cada projeto novamente e suporte todos os bugs irritantes causados ​​por ele (pelo menos costumava acontecer quando eu finalmente me cansava dele e apenas colocava os arquivos no GAC). Ambas as abordagens podem causar dores de cabeça e criar problemas; é apenas uma questão de quais problemas você prefere lidar. A Microsoft recomenda usar o sistema de pepitas e, geralmente, é melhor ouvi-los do que um programador desconhecido no SO, a menos que você esteja completamente cansado do sistema de pepitas e que lide com o GAC por tempo suficiente para que seja uma alternativa melhor. para voce. faça o download da pepita para cada projeto novamente e aguente todos os bugs irritantes causados ​​por ela (pelo menos costumava acontecer quando eu finalmente me cansava e colocava os arquivos no GAC). Ambas as abordagens podem causar dores de cabeça e criar problemas; é apenas uma questão de quais problemas você prefere lidar. A Microsoft recomenda usar o sistema de pepitas e, geralmente, é melhor ouvi-los do que um programador desconhecido no SO, a menos que você esteja completamente cansado do sistema de pepitas e que lide com o GAC por tempo suficiente para que seja uma alternativa melhor. para voce.

Basta adicionar o próximo pacote de pepitas ao seu projeto - Microsoft.CodeDom.Providers.DotNetCompilerPlatform.

Teve o mesmo problema.

Tenho o mesmo problema que meu aplicativo funcionou no Vs2013, mas obtendo o erro após a atualização para o Vs2015.

1. No Vs2015, clique com o botão direito do mouse na pasta Referências do projeto, para abrir o NuGet Package Manager
2. Na guia Procurar, procure "DotNetCompilerPlatform" e instale "Microsoft.CodeDom.Providers.DotNetCompilerPlatform" lib

Eu sei que é um encadeamento antigo, mas gostaria de apontar o possível problema de versão do DotNetCompilerPlatform.dll, f. ex. após uma atualização. Verifique se o novo arquivo Web.config gerado é diferente do seu web.config lançado, em particular a parte system.codedom. No meu caso, foi a alteração da versão de 1.0.7 para 1.0.8. A nova dll já havia sido copiada para o servidor, mas não alterei o antigo web.config (com algumas configurações especiais do 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>

Depois de atualizar as duas linhas, o erro desapareceu.

De acordo com as etapas de reprodução, presumi que alterar o caminho de saída na propriedade do aplicativo fosse sua única alteração após a criação do aplicativo. A única coisa que essa alteração faz é dizer ao Visual Studio para colocar os assemblies de saída do MSBuild na nova pasta. No tempo de execução, no entanto, o ASP.Net não fazia ideia de que deveria carregar assemblies dessa nova pasta em vez da pasta \ bin.

Esta resposta mostra a maneira de alterar o diretório de saída da construção de um aplicativo WebApi. Para obter exatamente o mesmo erro mostrado nessa publicação, é necessário comentar a seção <system.codedom> inteira em web.config. E então você pode seguir as instruções para alterar o caminho da saída.

Após o trabalho de aplicação, você pode descomentar a seção <system.codedom>. Se você não usar a nova sintaxe C # 6 em seu aplicativo, poderá desinstalar o Microsoft.CodeDom.Providers.DotNetCompilerPlatform do seu aplicativo; caso contrário, convém adicionar a seguinte linha de comando no evento pós-compilação,

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

O novo provedor CodeDom sempre procura a pasta "\ roslyn" em \ bin. O comando acima funciona como uma solução alternativa e copia a pasta \ roslyn da sua nova pasta de saída para \ bin.

Em meus experimentos, a ferramenta de publicação do Visual Studio, no entanto, publicou os assemblies de saída na pasta \ bin no local de implantação, independentemente da configuração do caminho de saída. Eu acho que seu aplicativo ainda deve funcionar na implantação real.

Maneira fácil - Projeto> Gerenciar pacotes NuGet ...> Navegar (guia)> na entrada de pesquisa, configure isto: Microsoft.CodeDom.Providers.DotNetCompilerPlatform

Você pode instalar ou atualizar ou desinstalar e instalar este compilador

Outra solução possível:

Reinicie sua instância do Visual Studio com direitos de administrador

Ele parou após a publicação no servidor de produção. A razão pela qual ele me mostrou esse erro foi porque foi implantado em uma subpasta . No IIS, cliquei na subpasta e executei "Converter em aplicativo" e, depois disso, funcionou.

No meu caso, isso aconteceu quando alterei a permissão da pasta do aplicativo e a conta IIS_IUSRS foi removida. Depois de adicionar novamente o IIS_IUSRS (Gerenciador do IIS-> YourWebApp -> Editar permissão -> Adicionar IIS_IUSRS) à pasta do aplicativo e funcionou.

Aqui está como eu o resolvi :

1. Excluiu a binpasta no diretório do projeto.
2. Clique em Build Solution. No VS2017 (Executar como administrador)> Compilar> Compilar Solução .

Se você estiver usando git, provavelmente estará ignorando a .dll na confirmação

Eu tinha vários projetos na solução e o projeto da Web (problema com esse erro) não foi definido como o projeto StartUp. Eu configurei esse projeto da Web como o projeto StartUp e cliquei no item de menu "Debug" -> "Start Debugging" e funcionou. Parei a depuração e tentei novamente e agora está de volta ao trabalho. Esquisito.

Então o problema voltou. Eu desinstalei ambos Microsoft.CodeDom.Providers.DotNetCompilerPlatforme Uninstall-package Microsoft.Net.Compilers, mas não ajuda. Então instalado - sem ajuda. Projeto limpo e sem ajuda. Em seguida, reparei que o projeto não precisava do mais recente, que atualmente é 1.0.5, mas 1.0.3, pois esse foi o erro que não pôde carregar a versão 1.0.3. Então eu instalei a versão dll e agora ele funciona.

O ASP.NET não pesquisa bin/debugnem subpastas na lixeira por montagens, como outros tipos de aplicativos. Você pode instruir o tempo de execução a procurar em um local diferente usando a seguinte configuração:

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

Você deve atualizar os pacotes "Microsoft.CodeDom.Providers.DotNetCompilerPlatform" e "Microsoft.Net.Compilers" no seu projeto.

No meu caso, recebi o erro quando tive meu aplicativo Web no 4.5.2 e as bibliotecas de classes referenciadas no 4.6.1. Quando atualizei o aplicativo Web para a versão 4.5.2, o erro desapareceu.

Eu estava recebendo esse erro porque meu usuário do pool de aplicativos foi definido como ApplicationPoolIdentity. Mudei para uma conta de usuário / serviço que tem acesso à pasta e o erro desapareceu.

Aqui estão minhas descobertas. Eu também enfrentei esse problema hoje de manhã. Acabei de adicionar meu usuário atual ao pool de aplicativos em que o aplicativo estava sendo executado.

Passos:

1. Abra o IIS

2. Clique no pool de aplicativos

3. Selecione seu pool de aplicativos no qual você está tendo problemas

4. Clique com o botão direito -> configurações avançadas

5. Clique no ícone de três pontos ao lado da identificação

6. Agora selecione uma conta personalizada

7. Dê o nome de usuário e a senha do seu PC

8. Salve 

Atualize seu aplicativo .. e ele começará a funcionar. Houve algum problema de segurança ao acessar a dll.

basta desinstalar o pacote do console do gerenciador de pacotes a partir do comando abaixo

PM> Desinstalar pacote Microsoft.CodeDom.Providers.DotNetCompilerPlatform

PM> Desinstalar pacote Microsoft.Net.Compilers

e instale-o novamente a partir do gerenciador de nuget

Se você instalou ou atualizou recentemente o Microsoft.CodeDom.Providers.DotNetCompilerPlatformpacote, verifique duas vezes se as versões desse pacote referenciadas no seu projeto apontam para a versão correta e a mesma do pacote:

• Em ProjectName.csproj, verifique se há uma <Import>tag para Microsoft.CodeDom.Providers.DotNetCompilerPlatforme aponte para a versão correta.

• Em ProjectName.csproj, verifique se há uma <Reference>tag para Microsoft.CodeDom.Providers.DotNetCompilerPlatforme aponte para a versão correta, tanto no Includeatributo quanto no filho <HintPath>.

• Nesse projeto web.config, verifique se a <system.codedom>tag está presente e se suas <compiler>tags filho têm a mesma versão em seus typeatributos.

Por alguma razão, no meu caso uma atualização deste pacote de 1.0.5 para 1.0.8 causou a <Reference>tag no .csprojde ter o seu Includeapontando para a antiga versão 1.0. 5 .0 (que eu havia excluído após a atualização do pacote), mas todo o resto estava apontando para a nova e correta versão 1.0. 8 .0.

Verifique se o seu projeto foi totalmente construído!

Clique na guia 'Saída' e verifique se você não tem algo como:

========== Reconstruir tudo: 14 foram bem-sucedidos, 1 falhou, 0 foi ignorado =========

E abra sua binpasta e verifique se está atualizada.

Eu tive um monte de erros de digitação que ignorei no começo, esquecendo que eles estavam quebrando a compilação e levando a que não houvesse DLLs copiadas.

Adicione uma referência ao assembly CppCodeProvider.

No meu caso, meu projeto da web não foi carregado corretamente (estava exibindo o projeto indisponível), então tive que recarregar meu projeto da web depois de abrir o meu visual studio no modo de administração, e tudo funcionou bem.

Eu apenas tive o mesmo problema e foi porque mudei o local do projeto e simplesmente precisava recriar o diretório virtual.

A exceção em que encontramos não foi no local, mas no servidor remoto, o IC do Azure estava lendo-o na pasta packages, mas as versões do compilador mencionadas acima não foram encontradas.

Para corrigir isso, modificamos o arquivo do projeto para torná-lo algo como

Não está referenciando nenhum dos pacotes aqui referenciando diretamente as variáveis ​​de ambiente.

Isso corrigiu o problema, no entanto, em nossos casos, não usamos pacotes diretamente do "package.config", em vez disso, temos uma pasta separada para manter a integridade da versão entre as equipes.

Vá para inetmgr a partir do comando start No console do gerenciador do IIS, escolha a pasta do aplicativo em Site padrão, clique com o botão direito do mouse nessa pasta e, em seguida, em Converter em aplicativo. Execute o arquivo .asmx ativando.

Verifique se a BINpasta foi carregada completamente ou está faltando nos arquivos.

Em relação a esse erro, tentei:

• Limpando e reconstruindo o projeto
• Descarregar e recarregar o projeto
• Modificando a estrutura de destino
• Modificando o caminho de saída
• Adicionando pepitas ao GAC
• Excluindo os pacotes uninstall-package Microsoft.CodeDom.Providers.DotNetCompilerPlatform uninstall-package Microsoft.Net.Compilerse instalando-os novamente.

Enquanto todas essas parecem soluções válidas, eu só consegui gerar novos erros e, no final, o erro parece ser exibido quando algumas referências / pepitas estão ausentes.

No meu caso, eu havia reinstalado o Microsoft Office recentemente e estava fazendo referência a assemblies como o Microsoft.Office.Core. A nova instalação não parecia incluir os pacotes necessários, o que fez com que minha solução não pudesse ser criada corretamente.

Consegui resolver esse problema refazendo meu código até o ponto em que não precisei fazer referência ao Microsoft.Office, mas poderia ter resolvido pesquisando os pacotes necessários e instalando-os adequadamente.

Parece uma mensagem de erro pouco clara do Visual Studio.

Se você estiver trabalhando em um projeto e isso agora aparecer como um erro. Reinicie o seu computador (ou servidor no meu caso), isso corrigiu o problema para mim.