Impossible de charger le type 'System.Runtime.CompilerServices.ExtensionAttribute' à partir de l'assembly 'mscorlib

Lors du démarrage de mon site Web pour la première fois, j'obtiens cette erreur

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

Qu'est-ce que je fais mal?

J'utilise .NET 4 et je démarre le site à partir de Visual Studio.

La seule chose que j'ai changé récemment est d'ajouter Simple Injector (via Nuget) dans mon projet.

Voici la trace de la pile

[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 première ligne de toutes les vues est mise en surbrillance et lorsque vous les survolez, vous obtenez cette erreur

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

Impossible de charger le type «System.Runtime.CompilerServices.ExtensionAttribute» à partir de l'assembly mscorlib

Oui, cela peut techniquement mal tourner lorsque vous exécutez du code sur .NET 4.0 au lieu de .NET 4.5. L'attribut a été déplacé de System.Core.dll vers mscorlib.dll dans .NET 4.5. Bien que cela ressemble à un changement de rupture plutôt désagréable dans une version de framework qui est censée être 100% compatible, un attribut [TypeForwardedTo] est censé rendre cette différence inobservable.

Comme Murphy le voudrait, chaque changement bien intentionné comme celui-ci a au moins un mode d'échec auquel personne n'a pensé. Cela semble mal tourner lorsque ILMerge a été utilisé pour fusionner plusieurs assemblys en un seul et que cet outil n'a pas été utilisé correctement. Un bon article de rétroaction qui décrit cette casse est ici . Il renvoie à un article de blog qui décrit l'erreur. C'est un article plutôt long, mais si je l'interprète correctement, la mauvaise option de ligne de commande ILMerge provoque ce problème:

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

Ce qui est incorrect. Lorsque vous installez 4.5 sur la machine qui construit le programme, les assemblys de ce répertoire sont mis à jour de 4.0 à 4.5 et ne sont plus adaptés à la cible 4.0. Ces assemblées ne devraient vraiment plus être là mais ont été conservées pour des raisons de compatibilité. Les assemblys de référence appropriés sont les assemblys de référence 4.0, stockés ailleurs:

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

Les solutions possibles sont donc de revenir à 4.0 sur la machine de construction, d'installer .NET 4.5 sur la machine cible et le correctif réel, de reconstruire le projet à partir du code source fourni, en corrigeant la commande ILMerge.

Notez que ce mode d'échec n'est pas exclusif à ILMerge, c'est juste un cas très courant. Tout autre scénario dans lequel ces assemblys 4.5 sont utilisés comme assemblys de référence dans un projet qui cible la version 4.0 est susceptible d'échouer de la même manière. À en juger par d'autres questions, un autre mode d'échec courant est celui des serveurs de construction qui ont été configurés sans utiliser de licence VS valide. Et en oubliant que les packs multi-ciblage sont téléchargeables gratuitement .

L'utilisation des assemblys de référence dans le sous-répertoire c: \ program files (x86) est une exigence absolue. À partir de .NET 4.0, il est déjà important d'éviter de prendre accidentellement une dépendance sur une classe ou une méthode ajoutée dans les versions 4.01, 4.02 et 4.03. Mais absolument indispensable maintenant que la version 4.5 est sortie.

J'ai eu ce problème, sauf que le type qu'il ne pouvait pas charger était System.Reflection.AssemblyMetadataAttribute. L'application Web a été construite sur une machine avec .NET 4.5 installé (fonctionne bien là-bas), avec 4.0 comme cadre cible, mais l'erreur s'est présentée lorsqu'elle était exécutée sur un serveur Web avec seulement 4.0 installé. Je l'ai ensuite essayé sur un serveur Web avec 4.5 installé et il n'y avait aucune erreur. Donc, comme d'autres l'ont dit, tout cela est dû à la manière délicate dont Microsoft a publié 4.5, qui est essentiellement une mise à niveau (et un écrasement de) la version 4.0. L'assembly System.Reflection fait référence à un type qui n'existe pas dans la version 4.0 (AssemblyMetadataAttribute), il échouera donc si vous n'avez pas le nouveau System.Reflection.dll.

Vous pouvez soit installer .NET 4.5 sur le serveur Web cible, soit créer l'application sur un ordinateur sur lequel 4.5 n'est pas installé. Loin d'une résolution idéale.

J'ai eu exactement le même problème avec un site (Kentico CMS), en commençant le développement en 4.5, en découvrant que le serveur de production ne supporte que 4.0, j'ai essayé de revenir au cadre cible de 4.0. Compiler les autres articles de ce fil de discussion (en particulier en changeant le framework cible en .Net 4 et .Net 4.5 toujours référencés). J'ai cherché dans ma solution et j'ai trouvé qu'une poignée de packages NuGet utilisaient encore des bibliothèques avec 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>

J'ai changé le cadre cible des projets en 4.5, supprimé toutes les bibliothèques NuGet, redescendu à 4.0 et rajouté les bibliothèques (j'ai dû utiliser certaines versions précédentes qui ne dépendaient pas 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>

Je viens de rencontrer ce problème ennuyeux aujourd'hui. Nous utilisons SmartAssembly pour emballer / masquer nos assemblages .NET, mais soudainement, le produit final ne fonctionnait pas sur nos systèmes de test. Je ne pensais même pas avoir .NET 4.5, mais apparemment quelque chose l'a installé il y a environ un mois.

J'ai désinstallé 4.5 et réinstallé 4.0, et maintenant tout fonctionne à nouveau. Pas trop impressionné d'avoir soufflé un après-midi là-dessus.

J'ai rencontré le même problème en essayant de lire des données à partir d'une base de données Firebird. Après de nombreuses heures de recherche, j'ai découvert que le problème était dû à une erreur que j'avais faite dans la requête. Le réparer l'a fait fonctionner parfaitement. Cela n'avait rien à voir avec la version du Framework

Nous avons rencontré ce problème et l'avons retrouvé sur Geocoding.net NuGet package que nous pour aider avec nos vues Google Maps (Geocoding.net version 3.1.0 publiée le 2/4/2014).

La dll Geocoding semble être .Net 4.0 lorsque vous examinez le fichier du package ou l'affichez à l'aide de l'application Dot Peek de Jet Brains; cependant, un de mes collègues dit qu'il a été compilé en utilisant ilmerge donc il est très probablement lié aux problèmes ilmerge énumérés ci-dessus.

Ce fut un long processus pour le retrouver. Nous avons récupéré différents ensembles de modifications à partir de TFS jusqu'à ce que nous les ayons réduits à l'ensemble de modifications qui a ajouté le package NuGet susmentionné. Après l'avoir supprimé, nous avons pu déployer sur notre serveur .NET 4.

Dans mon cas, après la rétrogradation de .NET 4.5 à .NET 4.0, le projet fonctionnait bien sur une machine locale, mais échouait sur le serveur après la publication.

Il s'avère que cette destination avait d'anciens assemblys, qui faisaient toujours référence à .NET 4.5.

Correction du problème en activant l'option de publication "Supprimer tous les fichiers existants avant la publication"

Dans mon cas, c'était Blend SDK qui a manqué la machine TeamCity. Cela a provoqué l'erreur en raison d'une méthode d'assemblage incorrecte.

Il suffit d'ajouter cette réponse pour aider Google à économiser les heures que j'ai passées pour arriver ici. J'ai utilisé ILMerge sur mon projet .Net 4.0, sans le jeu d'options / targetplatform, en supposant qu'il serait détecté correctement à partir de mon assemblage principal. J'ai ensuite eu des plaintes d'utilisateurs uniquement sur Windows XP aka WinXP. Cela a maintenant du sens car XP n'aura jamais> .Net 4.0 installé, contrairement à la plupart des systèmes d'exploitation plus récents. Donc, si vos utilisateurs XP rencontrent des problèmes, consultez les correctifs ci-dessus.

Dans mon cas, j'ai eu un problème avec l'utilisation de Microsoft.ReportViewer.WebForms. J'ai supprimé validate = true de la add verbligne dans web.config et cela a commencé à fonctionner:

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