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

159

É 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

insira a descrição da imagem aqui

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.

cscmh99
fonte
Posso perguntar por que você alterou o caminho de saída do seu aplicativo da web? Obrigado.
X-Mao
Essa exceção está acontecendo comigo toda vez que atualizo um aplicativo ASP.NET MVC executado anteriormente durante a compilação do msbuild .
Nikolay Kostov
A mesma coisa aconteceu comigo. Tudo começou depois que adicionei referências a algumas bibliotecas .dll. Corrigi-o desinstalando e reinstalando as bibliotecas. E não tenho idéia de por que isso aconteceu tudo ..
Letie Techera

Respostas:

127

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>

vibs2006
fonte
4
Estou preso no "erro do servidor no aplicativo '/'" há cerca de um dia. Estou compilando um aplicativo simples Hello World no Visual Studio 2015 e implantando-o em um servidor Web e obtendo esse erro. A remoção das linhas do <compiler> acima também fez com que esse problema desaparecesse. Gostaria de saber como isso acontece e se existe uma solução melhor. Acho que é bastante incrível que você não pode implantar um aplicativo Olá mundo, desta forma sem bater problemas, seus MS como não fazer qualquer teste: -)
user2728841
4
Para habilitar o Roslyn, você pode ver o seguinte artigo Habilitando a plataforma do compilador .NET ("Roslyn") em aplicativos ASP.NET Por que a compilação do Roslyn no ASP.NET? Permitindo que os novos compiladores Roslyn em seu aplicativo ASP.NET irá resultar em duas vantagens principais: suporte * para a nova linguagem apresenta * Potencialmente melhorou aplicativo de inicialização / pré-compilação tempo
vibs2006
1
Quando criei um novo projeto da web, ele veio com essas referências já existentes. Por que eles são instalados por padrão, qual é o seu objetivo? Também para meu entendimento, Roslyn é o novo compilador C #. Como removê-lo não interrompe o Visual Studio?
Jens Mander #
@JensMander ambos são tempos de execução de compilação. No IIS, precisamos ativar manualmente o Roslyn Compiler. Por favor, veja o link no meu comentário anterior sobre o artigo'Enabling the .NET Compiler Platform.
vibs2006
Eu tive o mesmo erro, finalmente atualizei o pacote mais recente para o Microsoft.CodeDom.Providers.DotNetCompilerPlatform resolvido para mim.
Red
48

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.

Yuval Perelman
fonte
40
Não deveria estar no GAC. O ponto principal da abordagem Nuget é fazer com que seu projeto use uma versão específica do C # ou VB.NET sem alterar nada no sistema host. Veja esta postagem de Damian Edwards, da MSFT: blogs.msdn.microsoft.com/webdev/2014/05/12/…
Sudhanshu Mishra 23/08/16
29
Esses assemblies NÃO pertencem ao período do GAC. Colocá-los no GAC resultará em uma eventual dor de cabeça quando alguém que precisar manter seu código não puder determinar por que o compilador errado é usado.
EKW
5
-1 para comentários da Microsoft. É como se fosse legal fazer isso hoje em dia. BTW, as pepitas têm muitas vantagens que as tornaram muito populares que você está simplesmente ignorando. Agora imagine o que os senhores da Microsoft pensariam disso.
Fabio Milheiro
2
@YuvalPerelman A Microsoft faz um monte de coisas destrutivas nos últimos 3-4 anos (como desestabilizar o Visual studio, produzindo produtos de qualidade muito baixa). Às vezes, até rezo para que toda a gerência do departamento de desenvolvimento seja demitida. No entanto, definitivamente não é esse o caso!
Maris
2
Obter essa dependência é a coisa mais impressionante que já vi há algum tempo.
Svend
31

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

Teve o mesmo problema.

Maris
fonte
Apenas tenha um pouco de cuidado; ele sobrescreve as 'compilerOptions' no web.config, portanto, salve os valores personalizados antes de instalar.
21418 Radderz
19

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
ninetiger
fonte
2
Obrigado pela dica re clicando com o botão direito Referências do projeto pasta para abrir o gerenciador de pacotes
garyh
3
Tente desinstalá-lo primeiro e depois instalá-lo novamente no NuGet. Isso funcionou para mim.
Matt
Você é uma lenda
Mo D Genesis
16

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.

Henry.K
fonte
1
Tenho problemas com DotNetCompilerPlatform cada único tempo que eu atualizá-lo.
LarryBud
2
Se você remover o atributo version, também funcionará e evitará que o erro seja gerado novamente na próxima atualização.
MiguelSlv
O mesmo problema que tive, exceto que tive que atualizar de 2.0.0para2.0.1
Rory McCrossan
12

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.

X-Mao
fonte
10

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

DotNetCompilerPlatform

Newred
fonte
8

Outra solução possível:

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

insira a descrição da imagem aqui

Legendas
fonte
4

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.

Martin Lietz
fonte
Converter em aplicativo era tudo o que eu precisava. (Era um novo projeto que não tivesse publicado antes.)
Patrick
O problema de usar uma subpasta também foi meu, então mudei para a pasta base e as coisas começaram a funcionar.
J_L
4

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.

O registro
fonte
Eu adicionei permissões IUSR, mas não eram adequadas. Eu tive que adicionar "IIS_IUSRS" e funcionou.
Zacharydl 14/03/19
3

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 .
Barba Negra
fonte
3

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

Antonio Reyes
fonte
2

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.

tfa
fonte
2

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.

tfa
fonte
1

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>
Nate Zaugg
fonte
1

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

salah eddine
fonte
1

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.

Mnaseem
fonte
Tem de fato o mesmo erro ao instalar Umbraco 8, para a versão .Net errado (necessário 4.7.2) em vez de 4.5.2 (default VS 2017)
Bunkerbuster
1

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.

user3822295
fonte
1

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.

Nekesh hedau
fonte
1

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 insira a descrição da imagem aqui

Hisham shahid
fonte
1

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.

Ian Kemp
fonte
1

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.

Simon_Weaver
fonte
1

Adicione uma referência ao assembly CppCodeProvider.

Pedreiro
fonte
1

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.

Rupesh Kumar Tiwari
fonte
0

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

Steven T. Cramer
fonte
0

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.

Vikas Sharma
fonte
0

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.

Prabha Rajan
fonte
0

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

TechDo
fonte
Eu também estou enfrentando o mesmo problema, muito novo para asp.net
Prashant Pimpale
0

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.

Wouter Vanherck
fonte
0

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.

MichaelDarkBlue
fonte