.net - No se pudo cargar el tipo ''System.Runtime.CompilerServices.ExtensionAttribute'' del ensamblado ''mscorlib

Question

Al iniciar mi sitio web por primera vez, recibo este error

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

¿Qué estoy haciendo mal?

Estoy usando .NET 4 y estoy comenzando el sitio desde Visual Studio.

Lo único que he cambiado recientemente es agregar Simple Injector (a través de Nuget) a mi proyecto.

Aquí está el rastro de la pila

[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

La primera línea de todas las vistas se resalta y cuando pasas el cursor sobre ellas obtienes este error

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

Answer 1

No se pudo cargar el tipo ''System.Runtime.CompilerServices.ExtensionAttribute'' del ensamblado mscorlib

Sí, técnicamente esto puede salir mal cuando ejecuta código en .NET 4.0 en lugar de .NET 4.5. El atributo se movió de System.Core.dll a mscorlib.dll en .NET 4.5. Si bien eso suena como un cambio bastante desagradable en una versión de framework que se supone que es 100% compatible, se supone que un atributo [TypeForwardedTo] hace que esta diferencia no sea observable.

Como Murphy lo tendría, cada cambio bien intencionado como este tiene al menos un modo de falla en el que nadie pensó. Esto parece ir mal cuando ILMerge se usó para combinar varios ensambles en uno y esa herramienta se usó incorrectamente. Un buen artículo de comentarios que describe esta rotura está aquí . Se vincula a una publicación de blog que describe el error. Es un artículo bastante largo, pero si lo interpreto correctamente, la opción incorrecta de la línea de comando de ILMerge causa este problema:

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

Que es incorrecto Cuando instala 4.5 en la máquina que crea el programa, los ensamblados en ese directorio se actualizan de 4.0 a 4.5 y ya no son aptos para alcanzar 4.0. Esas asambleas realmente no deberían estar allí más, pero se guardaron por razones de compatibilidad. Los conjuntos de referencia adecuados son los conjuntos de referencia 4.0, almacenados en otra parte:

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

Así que las soluciones posibles son retroceder a 4.0 en la máquina de compilación, instalar .NET 4.5 en la máquina de destino y la solución real, para reconstruir el proyecto a partir del código fuente provisto, arreglando el comando ILMerge.

Tenga en cuenta que este modo de falla no es exclusivo de ILMerge, es solo un caso muy común. Cualquier otro escenario en el que estos ensamblados 4.5 se utilicen como ensambles de referencia en un proyecto dirigido a 4.0 puede fallar de la misma manera. A juzgar por otras preguntas, otro modo de falla común es en los servidores de compilación que se configuraron sin usar una licencia VS válida. Y pasando por alto que los paquetes multi-targeting son de descarga gratuita .

Usar los ensamblados de referencia en el subdirectorio c: / Archivos de programa (x86) es un requisito difícil. Comenzando en .NET 4.0, ya es importante evitar accidentalmente tomar una dependencia de una clase o método que se agregó en las versiones 4.01, 4.02 y 4.03. Pero es absolutamente esencial ahora que se lanza 4.5.

Answer 2

En mi caso, después de la degradación de .NET 4.5 a .NET 4.0, el proyecto funcionaba bien en una máquina local, pero estaba fallando en el servidor después de la publicación.

Resulta que el destino tenía algunos ensamblajes antiguos, que todavía se referían a .NET 4.5.

Se corrigió habilitando la opción de publicación "Eliminar todos los archivos existentes antes de publicar"

Answer 3

En mi caso, fue Blend SDK perdido en la máquina de TeamCity. Esto provocó que se solucionara el error debido a una forma incorrecta de ensamblaje.

Answer 4

En mi caso, tuve un problema con el uso de Microsoft.ReportViewer.WebForms. Eliminé validate = true de add verb line en web.config y comenzó 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" />

Answer 5

Me encontré con el mismo problema al tratar de leer datos de una base de datos Firebird. Después de muchas horas de búsqueda, descubrí que el problema fue causado por un error que hice en la consulta. Arreglarlo lo hizo funcionar perfectamente. No tenía nada que ver con la versión del Marco

Answer 6

Me encontré con este molesto problema hoy. Usamos SmartAssembly para empacar / ofuscar nuestros ensamblados .NET, pero de repente el producto final no funcionaba en nuestros sistemas de prueba. Ni siquiera pensé que tenía .NET 4.5, pero aparentemente algo lo instaló hace aproximadamente un mes.

Desinstalé 4.5 y reinstalé 4.0, y ahora todo está funcionando nuevamente. No muy impresionado con haber pasado una tarde en esto.

Answer 7

Nos encontramos con este problema y lo rastreamos hasta el paquete de Geocoding.net NuGet que estábamos utilizando para ayudar con nuestras vistas de Google Maps (Geocoding.net versión 3.1.0 publicada el 2/4/2014).

La dll Geocoding parece ser .Net 4.0 cuando examina el archivo del paquete o lo ve usando la aplicación Dot Peek de Jet Brains; sin embargo, un colega mío dice que se compiló utilizando ilmerge, por lo que está más relacionado con los problemas de ilmerge mencionados anteriormente.

Fue un proceso largo para rastrearlo. Cogimos diferentes conjuntos de cambios de TFS hasta que lo redujimos al conjunto de cambios que agregó el paquete NuGet antes mencionado. Después de eliminarlo, pudimos implementarlo en nuestro servidor .NET 4.

Answer 8

Solo agregué esta respuesta para ayudar a Google a ahorrarle a un apostador las horas que he pasado para llegar hasta aquí. Usé ILMerge en mi proyecto .Net 4.0, sin la opción / targetplatform establecida, suponiendo que se detectaría correctamente desde mi ensamblaje principal. Luego tuve quejas de los usuarios solo en Windows XP, también conocido como WinXP. Esto ahora tiene sentido ya que XP nunca tendrá instalado .Net 4.0, mientras que la mayoría de los sistemas operativos más nuevos lo harán. Entonces, si sus usuarios de XP tienen problemas, consulte las soluciones anteriores.

Answer 9

Tuve este problema, excepto que el tipo que no pudo cargar fue System.Reflection.AssemblyMetadataAttribute. La aplicación web se creó en una máquina con .NET 4.5 instalado (funciona bien allí), con 4.0 como marco de destino, pero el error se presentó cuando se ejecutó en un servidor web con solo 4.0 instalado. Luego lo intenté en un servidor web con 4.5 instalado y no hubo ningún error. Entonces, como han dicho otros, todo esto se debe a la forma en que Microsoft lanzó 4.5, que básicamente es una actualización (y sobrescribir) de la versión 4.0. El ensamblado System.Reflection hace referencia a un tipo que no existe en 4.0 (AssemblyMetadataAttribute) por lo que fallará si no tiene el nuevo System.Reflection.dll.

Puede instalar .NET 4.5 en el servidor web de destino o compilar la aplicación en una máquina que no tiene 4.5 instalado. Lejos de una resolución ideal.

Answer 10

Tuve exactamente el mismo problema con un sitio (Kentico CMS), comencé el desarrollo en 4.5, descubrí que el servidor de producción solo admite 4.0, intenté volver al marco de destino de 4.0. Compilando las otras publicaciones en este hilo (específicamente cambiando el marco de destino a .Net 4 y .Net 4.5 que todavía se referencian). Busqué a través de mi solución y encontré que un puñado de los paquetes NuGet aún usaban bibliotecas con 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>

Cambié el marco de destino de proyectos a 4.5, eliminé todas las bibliotecas NuGet, volví a 4.0 y volví a agregar las bibliotecas (tuve que usar algunas versiones anteriores que no dependían de 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>