Não foi possível carregar o tipo 'System.Runtime.CompilerServices.ExtensionAttribute' do assembly 'mscorlib

Ao iniciar meu site pela primeira vez, estou recebendo este erro

Could not load type 'System.Runtime.CompilerServices.ExtensionAttribute' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'

O que estou fazendo de errado?

Estou usando o .NET 4 e estou iniciando o site no Visual Studio.

A única coisa que mudei recentemente é adicionar o Simple Injector (via Nuget) ao meu projeto.

Aqui está o rastreamento de pilha

[TypeLoadException: Could not load type 'System.Runtime.CompilerServices.ExtensionAttribute' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.]
   System.ModuleHandle.ResolveType(RuntimeModule module, Int32 typeToken, IntPtr* typeInstArgs, Int32 typeInstCount, IntPtr* methodInstArgs, Int32 methodInstCount, ObjectHandleOnStack type) +0
   System.ModuleHandle.ResolveTypeHandleInternal(RuntimeModule module, Int32 typeToken, RuntimeTypeHandle[] typeInstantiationContext, RuntimeTypeHandle[] methodInstantiationContext) +180
   System.Reflection.RuntimeModule.ResolveType(Int32 metadataToken, Type[] genericTypeArguments, Type[] genericMethodArguments) +192
   System.Reflection.CustomAttribute.FilterCustomAttributeRecord(CustomAttributeRecord caRecord, MetadataImport scope, Assembly& lastAptcaOkAssembly, RuntimeModule decoratedModule, MetadataToken decoratedToken, RuntimeType attributeFilterType, Boolean mustBeInheritable, Object[] attributes, IList derivedAttributes, RuntimeType& attributeType, IRuntimeMethodInfo& ctor, Boolean& ctorHasParameters, Boolean& isVarArg) +115
   System.Reflection.CustomAttribute.GetCustomAttributes(RuntimeModule decoratedModule, Int32 decoratedMetadataToken, Int32 pcaCount, RuntimeType attributeFilterType, Boolean mustBeInheritable, IList derivedAttributes, Boolean isDecoratedTargetSecurityTransparent) +426
   System.Reflection.CustomAttribute.GetCustomAttributes(RuntimeAssembly assembly, RuntimeType caType) +103
   System.Reflection.RuntimeAssembly.GetCustomAttributes(Type attributeType, Boolean inherit) +64
   WebActivator.AssemblyExtensions.GetActivationAttributes(Assembly assembly) +132
   WebActivator.ActivationManager.RunActivationMethods() +216
   WebActivator.ActivationManager.RunPreStartMethods() +43
   WebActivator.ActivationManager.Run() +69

[InvalidOperationException: The pre-application start initialization method Run on type WebActivator.ActivationManager threw an exception with the following error message: Could not load type 'System.Runtime.CompilerServices.ExtensionAttribute' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'..]
   System.Web.Compilation.BuildManager.InvokePreStartInitMethods(ICollection`1 methods) +423
   System.Web.Compilation.BuildManager.CallPreStartInitMethods() +306
   System.Web.Hosting.HostingEnvironment.Initialize(ApplicationManager appManager, IApplicationHost appHost, IConfigMapPathFactory configMapPathFactory, HostingEnvironmentParameters hostingParameters, PolicyLevel policyLevel, Exception appDomainCreationException) +677

[HttpException (0x80004005): The pre-application start initialization method Run on type WebActivator.ActivationManager threw an exception with the following error message: Could not load type 'System.Runtime.CompilerServices.ExtensionAttribute' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'..]
   System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +9090876
   System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +97
   System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr) +258

A primeira linha de todas as visualizações é destacada e quando você passa o mouse sobre elas, esse erro é exibido.

The pre-application start initialisation method Run on type WebActivator.ActivationManager threw an exception with the following error message Could not load type 'System.Runtime.CompilerServices.ExtensionAttribute' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.

Não foi possível carregar o tipo 'System.Runtime.CompilerServices.ExtensionAttribute' do assembly mscorlib

Sim, isso tecnicamente pode dar errado quando você executa o código no .NET 4.0 em vez do .NET 4.5. O atributo foi movido de System.Core.dll para mscorlib.dll no .NET 4.5. Embora isso pareça uma mudança desagradável em uma versão do framework que seja 100% compatível, um atributo [TypeForwardedTo] deve fazer essa diferença não observável.

Como Murphy gostaria, toda mudança bem intencionada como essa tem pelo menos um modo de falha em que ninguém pensou. Isso parece dar errado quando o ILMerge foi usado para mesclar vários assemblies em um e essa ferramenta foi usada incorretamente. Um bom artigo de feedback que descreve essa quebra está aqui . Ele é vinculado a um post do blog que descreve o erro. É um artigo bastante longo, mas se eu o interpretar corretamente, a opção de linha de comando do ILMerge incorreta causará este problema:

  /targetplatform:"v4,c:\windows\Microsoft.NET\Framework\v4.0.30319"

O que está incorreto. Quando você instala o 4.5 na máquina que cria o programa, os assemblies nesse diretório são atualizados de 4.0 para 4.5 e não são mais adequados para o destino 4.0. Essas assembléias realmente não deveriam estar mais lá, mas foram mantidas por razões compatíveis. Os assemblies de referência adequados são os assemblies de referência 4.0, armazenados em outro local:

  /targetplatform:"v4,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0"

Portanto, as soluções possíveis são voltar para 4.0 na máquina de construção, instalar o .NET 4.5 na máquina de destino e a correção real, para reconstruir o projeto a partir do código-fonte fornecido, corrigindo o comando ILMerge.

Observe que esse modo de falha não é exclusivo do ILMerge, é apenas um caso muito comum. Qualquer outro cenário em que esses assemblies 4.5 sejam usados ​​como assemblies de referência em um projeto que se destina ao 4.0 é passível de falha da mesma maneira. A julgar por outras perguntas, outro modo de falha comum está nos servidores de compilação que foram configurados sem o uso de uma licença válida do VS. E com vista para o fato de que os pacotes de várias segmentações são um download gratuito .

Usar os assemblies de referência no subdiretório c: \ arquivos de programas (x86) é um requisito essencial. A partir do .NET 4.0, já é importante evitar a dependência acidental de uma classe ou método adicionado nas versões 4.01, 4.02 e 4.03. Mas absolutamente essencial agora que o 4.5 foi lançado.

Eu tive esse problema, exceto o tipo que não pôde carregar era System.Reflection.AssemblyMetadataAttribute. O aplicativo da Web foi construído em uma máquina com o .NET 4.5 instalado (funciona bem lá), com 4.0 como a estrutura de destino, mas o erro se apresentou quando foi executado em um servidor da Web com apenas o 4.0 instalado. Eu tentei em um servidor web com o 4.5 instalado e não houve erro. Portanto, como já foi dito, tudo isso se deve à maneira arrogante que a Microsoft lançou o 4.5, que basicamente é uma atualização para (e sobrescrita da) versão 4.0. O assembly System.Reflection faz referência a um tipo que não existe no 4.0 (AssemblyMetadataAttribute), portanto falhará se você não tiver o novo System.Reflection.dll.

Você pode instalar o .NET 4.5 no servidor da Web de destino ou criar o aplicativo em uma máquina que não possui o 4.5 instalado. Longe de uma resolução ideal.

Eu tive exatamente o mesmo problema com um site (Kentico CMS), iniciando o desenvolvimento no 4.5, descobrindo que o servidor de produção suporta apenas 4.0, tentei voltar para o framework de destino 4.0. Compilar as outras postagens neste segmento (alterando especificamente a estrutura de destino para .Net 4 e .Net 4.5 ainda sendo referenciadas). Eu procurei na minha solução e descobri que alguns pacotes do NuGet ainda estavam usando bibliotecas com targetFramework = "net45".

packages.config (before):
<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="AutoMapper" version="3.1.0" targetFramework="net45" />
  <package id="EntityFramework" version="5.0.0" targetFramework="net45" />
  <package id="Microsoft.AspNet.WebApi.Client" version="5.0.0" targetFramework="net45" />
  <package id="Newtonsoft.Json" version="4.5.11" targetFramework="net45" />
</packages>

Alterei a estrutura de destino dos projetos de volta para 4.5, removi todas as bibliotecas do NuGet, voltei para a 4.0 e adicionei novamente as bibliotecas (tive que usar algumas versões anteriores que não dependiam do 4.5).

packages.config (after):
<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="AutoMapper" version="3.1.1" targetFramework="net40" />
  <package id="EntityFramework" version="6.0.2" targetFramework="net40" />
  <package id="Microsoft.AspNet.WebApi.Client" version="4.0.30506.0" targetFramework="net40" />
  <package id="Microsoft.Net.Http" version="2.0.20710.0" targetFramework="net40" />
  <package id="Newtonsoft.Json" version="4.5.11" targetFramework="net40" />
</packages>

Eu acabei de encontrar este problema irritante hoje. Usamos o SmartAssembly para empacotar / ofuscar nossos assemblies .NET, mas de repente o produto final não estava funcionando em nossos sistemas de teste. Eu nem pensei que tinha o .NET 4.5, mas aparentemente algo o instalou cerca de um mês atrás.

Eu desinstalei o 4.5 e reinstalei o 4.0, e agora tudo está funcionando novamente. Não estou muito impressionado por ter passado uma tarde nisso.

Eu encontrei o mesmo problema ao tentar ler dados de um banco de dados Firebird. Após muitas horas de pesquisa, descobri que o problema foi causado por um erro que cometi na consulta. Consertá-lo fez funcionar perfeitamente. Não tinha nada a ver com a versão do Framework

Encontramos esse problema e o localizamos no pacote NuGet Geocoding.net que estávamos usando para ajudar com nossas visualizações do Google Maps (Geocoding.net versão 3.1.0 publicada em 04/02/2014).

A DLL de geocodificação parece ser .Net 4.0 quando você examina o arquivo do pacote ou o exibe usando o aplicativo Dot Peek da Jet Brains; no entanto, um colega meu diz que foi compilado usando o ilmerge, portanto, provavelmente está relacionado aos problemas do ilmerge listados acima.

Foi um longo processo para localizá-lo. Buscamos diferentes conjuntos de alterações do TFS até reduzi-lo ao conjunto de alterações que adicionou o pacote NuGet acima mencionado. Depois de removê-lo, conseguimos implantar no nosso servidor .NET 4.

No meu caso, após o downgrade do .NET 4.5 para o .NET 4.0, o projeto estava funcionando bem em uma máquina local, mas falhou no servidor após a publicação.

Acontece que esse destino tinha alguns assemblies antigos, que ainda faziam referência ao .NET 4.5.

Corrigido, ativando a opção de publicação "Excluir todos os arquivos existentes antes da publicação"

No meu caso, foi o SDK do Blend perdido na máquina TeamCity. Isso causou o erro devido à maneira incorreta de montagem resolver em seguida.

Basta adicionar esta resposta para ajudar o Google a economizar tempo nas horas que passei para chegar aqui. Usei o ILMerge no meu projeto .Net 4.0, sem a opção / targetplatform definida, assumindo que ele seria detectado corretamente no meu assembly principal. Recebi reclamações de usuários apenas no Windows XP, também conhecido como WinXP. Isso agora faz sentido, pois o XP nunca terá o .Net 4.0 instalado, enquanto a maioria dos sistemas operacionais mais novos o fará. Portanto, se os usuários do XP estiverem com problemas, consulte as correções acima.

No meu caso, tive um problema ao usar o Microsoft.ReportViewer.WebForms. Eu removi validate = true da add verblinha no web.config e ele começou a funcionar:

<system.web>
    <httpHandlers>
      <add verb="*" path="Reserved.ReportViewerWebControl.axd" type="Microsoft.Reporting.WebForms.HttpHandler, Microsoft.ReportViewer.WebForms, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />