Nie można załadować typu „System.Runtime.CompilerServices.ExtensionAttribute” z zestawu „mscorlib”

Podczas pierwszego uruchamiania witryny sieci Web pojawia się ten błąd

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

Co ja robię źle?

Używam .NET 4 i uruchamiam witrynę w programie Visual Studio.

Jedyną rzeczą, którą ostatnio zmieniłem, jest dodanie prostego wtryskiwacza (przez Nuget) do mojego projektu.

Oto ślad stosu

[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

Pierwsza linia wszystkich widoków zostaje podświetlona, ​​a po najechaniu na nie kursorem pojawia się ten błąd

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

Nie można załadować typu „System.Runtime.CompilerServices.ExtensionAttribute” z mscorlib zestawu

Tak, to technicznie może się nie udać, gdy wykonujesz kod na .NET 4.0 zamiast .NET 4.5. Atrybut został przeniesiony z System.Core.dll do mscorlib.dll w .NET 4.5. Chociaż brzmi to jak raczej nieprzyjemna, przełomowa zmiana w wersji frameworka, która ma być w 100% zgodna, atrybut [TypeForwardedTo] powinien sprawić, że ta różnica będzie nieobserwowalna.

Tak jak chciałby Murphy, każda dobrze zaplanowana zmiana, taka jak ta, ma przynajmniej jeden tryb awarii, o którym nikt nie pomyślał. Wydaje się, że dzieje się to źle, gdy ILMerge został użyty do scalenia kilku zestawów w jeden i to narzędzie zostało użyte nieprawidłowo. Dobry artykuł z opiniami, który opisuje tę przerwę, jest tutaj . Prowadzi do posta na blogu, w którym opisano błąd. Jest to dość długi artykuł, ale jeśli zinterpretuję go poprawnie, to zła opcja wiersza poleceń ILMerge powoduje ten problem:

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

Co jest niepoprawne. Podczas instalowania 4.5 na komputerze, na którym budowany jest program, zestawy w tym katalogu są aktualizowane z 4.0 do 4.5 i nie są już odpowiednie dla wersji docelowej 4.0. Te zgromadzenia naprawdę nie powinny już tam być, ale zostały zachowane ze względów kompatybilności. Właściwe zestawy referencyjne to zestawy referencyjne 4.0, przechowywane w innym miejscu:

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

Tak więc możliwe obejścia to powrót do wersji 4.0 na maszynie budującej, zainstalowanie .NET 4.5 na maszynie docelowej i rzeczywista poprawka, aby przebudować projekt z dostarczonego kodu źródłowego, naprawiając polecenie ILMerge.

Zwróć uwagę, że ten tryb awarii nie jest wyłączny dla ILMerge, jest po prostu bardzo częstym przypadkiem. Każdy inny scenariusz, w którym te zestawy 4,5 są używane jako zestawy referencyjne w projekcie, który jest przeznaczony dla 4.0, może zakończyć się niepowodzeniem w ten sam sposób. Sądząc po innych pytaniach, innym częstym trybem awarii są serwery kompilacji, które zostały skonfigurowane bez użycia ważnej licencji VS. Pomijając fakt, że pakiety kierowania na wiele celów można pobrać bezpłatnie .

Korzystanie z zestawów referencyjnych w podkatalogu c: \ program files (x86) jest bardzo trudne. Począwszy od .NET 4.0, już ważne, aby uniknąć przypadkowego uzależnienia się od klasy lub metody, która została dodana w wersjach 4.01, 4.02 i 4.03. Ale absolutnie niezbędne teraz, gdy wydano 4.5.

Miałem ten problem, z wyjątkiem tego, że typ, którego nie można załadować, to System.Reflection.AssemblyMetadataAttribute. Aplikacja internetowa została zbudowana na komputerze z zainstalowanym .NET 4.5 (działa tam dobrze), z 4.0 jako platformą docelową, ale błąd pojawił się, gdy została uruchomiona na serwerze WWW z zainstalowanym tylko 4.0. Następnie wypróbowałem to na serwerze sieciowym z zainstalowaną wersją 4.5 i nie było żadnego błędu. Tak więc, jak powiedzieli inni, to wszystko z powodu dziwacznego sposobu, w jaki Microsoft wydał 4.5, który w zasadzie jest aktualizacją do (i nadpisaniem) wersji 4.0. Zestaw System.Reflection odwołuje się do typu, który nie istnieje w 4,0 (AssemblyMetadataAttribute), więc zakończy się niepowodzeniem, jeśli nie masz nowego System.Reflection.dll.

Możesz zainstalować .NET 4.5 na docelowym serwerze internetowym lub skompilować aplikację na komputerze, na którym nie ma zainstalowanej wersji 4.5. Daleko od idealnej rozdzielczości.

Miałem dokładnie ten sam problem z witryną (Kentico CMS), zaczynając rozwój w 4.5, stwierdzając, że serwer produkcyjny obsługuje tylko 4.0, próbowałem wrócić do docelowego frameworka 4.0. Kompilowanie innych postów w tym wątku (w szczególności zmiana platformy docelowej na .Net 4 i .Net 4.5 nadal przywoływane). Przeszukałem moje rozwiązanie i stwierdziłem, że kilka pakietów NuGet nadal używa bibliotek z 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>

Zmieniłem strukturę docelową projektów z powrotem na 4,5, usunąłem wszystkie biblioteki NuGet, wróciłem do 4.0 i ponownie dodałem biblioteki (musiałem użyć niektórych poprzednich wersji, które nie były zależne od 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>

Właśnie dzisiaj napotkałem ten irytujący problem. Używamy SmartAssembly do pakowania / zaciemniania naszych zestawów .NET, ale nagle produkt końcowy przestał działać w naszych systemach testowych. Nawet nie sądziłem, że mam .NET 4.5, ale podobno coś go zainstalowało około miesiąc temu.

Odinstalowałem 4.5 i przeinstalowałem 4.0 i teraz wszystko znowu działa. Nie jestem pod wrażeniem spędzonego na tym popołudnia.

Napotkałem ten sam problem podczas próby odczytu danych z bazy danych Firebird. Po wielu godzinach poszukiwań okazało się, że przyczyną problemu był błąd, który popełniłem w zapytaniu. Naprawienie tego sprawiło, że działało idealnie. Nie miało to nic wspólnego z wersją Framework

Napotkaliśmy ten problem i wyśledziliśmy go w pakiecie NuGet Geocoding.net , którego używaliśmy do pomocy w naszych widokach Map Google (Geocoding.net w wersji 3.1.0 opublikowany 2/4/2014).

Plik dll Geocoding wygląda na .Net 4.0, gdy sprawdzasz plik pakietu lub przeglądasz go za pomocą aplikacji Dot Peek firmy Jet Brains; jednak mój kolega mówi, że został on skompilowany przy użyciu ilmerge, więc najprawdopodobniej jest to związane z wymienionymi powyżej problemami ilmerge.

Wytropienie go było długim procesem. Pobraliśmy różne zestawy zmian z TFS, dopóki nie zawęziliśmy ich do zestawu zmian, który dodał wspomniany pakiet NuGet. Po jego usunięciu mogliśmy wdrożyć na naszym serwerze .NET 4.

W moim przypadku po przejściu z .NET 4.5 na .NET 4.0 projekt działał dobrze na komputerze lokalnym, ale po opublikowaniu kończył się niepowodzeniem na serwerze.

Okazuje się, że miejsce docelowe zawierało kilka starych zestawów, które nadal odwoływały się do platformy .NET 4.5.

Naprawiono to, włączając opcję publikowania „Usuń wszystkie istniejące pliki przed opublikowaniem”

W moim przypadku był to Blend SDK pominięty na maszynie TeamCity. Spowodowało to błąd spowodowany wówczas nieprawidłowym sposobem rozwiązania montażu.

Wystarczy dodać tę odpowiedź, aby pomóc Google zaoszczędzić niektórym klientom godziny, które spędziłem, aby się tu dostać. Użyłem ILMerge w moim projekcie .Net 4.0, bez zestawu opcji / targetplatform, zakładając, że zostanie on poprawnie wykryty z mojego głównego zestawu. Wtedy otrzymałem skargi od użytkowników tylko na Windows XP, czyli WinXP. Teraz ma to sens, ponieważ XP nigdy nie będzie miał zainstalowanego> .Net 4.0, podczas gdy większość nowszych systemów operacyjnych będzie. Jeśli więc użytkownicy XP mają problemy, zobacz poprawki powyżej.

W moim przypadku miałem problem z używaniem Microsoft.ReportViewer.WebForms. Usunąłem validate = true z add verblinii w web.config i zaczęło działać:

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