Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


  • Rune Grønkjær 1372 posts 3103 karma points
    Sep 28, 2012 @ 10:29
    Rune Grønkjær
    0

    Umbraco 4.9 Could not load type 'System.Runtime.CompilerServices.ExtensionAttribute'

    Hi Guys,

    I have just upgraded from Umbraco 4.8.1 to 4.9 and everything seems to work, with the exeption of package installation. When trying to install any package I get the YSOD below. This happened for me with two different packages and will probably also be a problem with other packages.

    It seems like something is missing. But I have all the 4.9 files, and using WinMerge the only difference in the bin folder is the other package dll's, which I installed when the website where version 4.8.1.

    Anyone know of this problem?

    My nice YSOD

    Server Error in '/' Application.

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

    Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. 

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

    Source Error: 

    The source code that generated this unhandled exception can only be shown when compiled in debug mode. To enable this, please follow one of the below steps, then request the URL:

    1. Add a "Debug=true" directive at the top of the file that generated the error. Example:

      <%@ Page Language="C#" Debug="true" %>

    or:

    2) Add the following section to the configuration file of your application:

    <configuration>
       <system.web>
           <compilation debug="true"/>
       </system.web>
    </configuration>

    Note that this second technique will cause all files within a given application to be compiled in debug mode. The first technique will cause only that particular file to be compiled in debug mode.

    Important: Running applications in debug mode does incur a memory/performance overhead. You should make sure that an application has debugging disabled before deploying into production scenario.


    Stack Trace: 

    [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(Boolean inherit) +33
       System.Web.UI.AssemblyCache.GetAjaxFrameworkAssemblyAttribute(Assembly assembly) +76
       System.Web.UI.ScriptManager.get_DefaultAjaxFrameworkAssembly() +399
       System.Web.UI.ScriptManager..ctor() +26
       ASP.umbraco_masterpages_umbracopage_master.__BuildControlScriptManager1() +25
       ASP.umbraco_masterpages_umbracopage_master.__BuildControlform1() +133
       ASP.umbraco_masterpages_umbracopage_master.__BuildControlTree(umbraco_masterpages_umbracopage_master __ctrl) +179
       ASP.umbraco_masterpages_umbracopage_master.FrameworkInitialize() +22
       System.Web.UI.UserControl.InitializeAsUserControlInternal() +35
       System.Web.UI.MasterPage.CreateMaster(TemplateControl owner, HttpContext context, VirtualPath masterPageFile, IDictionary contentTemplateCollection) +8965442
       System.Web.UI.Page.get_Master() +54
       System.Web.UI.Page.ApplyMasterPage() +15
       System.Web.UI.Page.PerformPreInit() +45
       System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +328
    



    Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.272

     

    Thanks

    /Rune

  • Lee Kelleher 4026 posts 15836 karma points MVP 13x admin c-trib
    Sep 28, 2012 @ 11:40
    Lee Kelleher
    3

    Hi Rune,

    I ran into a similar problem yesterday - but not with Umbraco core upgrade, but a 3rd-party package.

    Investigating the exception I found the root cause to be that the "ExtensionAttribute" had been moved from "System.Core" (in .NET 4.0) to "mscorlib" (in .NET 4.5) ... what this means is that one of the DLLs in your /bin folder has been compiled against .NET 4.5 instead of .NET 4.0.

    I don't think it's Umbraco 4.9, as that works fine on my laptop (which only has .NET 4.0 installed).

    Your options are:

    • Install .NET 4.5 on your machine/web-server.
    • Find the culprit DLL and ask the developer(s) to recompile it against .NET 4.0.

    Good luck!

    Cheers, Lee.

  • Rune Grønkjær 1372 posts 3103 karma points
    Sep 28, 2012 @ 13:44
    Rune Grønkjær
    0

    YES. Lee Kelleher FTW.

    Thanks. Installing .NET 4.5 was the cure.

    /Rune

  • Murray Roke 503 posts 966 karma points c-trib
    Feb 21, 2013 @ 05:05
    Murray Roke
    0

    How do you find the culprit DLL?

    Also I should clarify, when Lee says compile against 4.0 he does not mean target 4.0 he means compile it on a PC that does not even have 4.5 installed. 

    Or... fix how they're using ILMerge (there may be other root causes also, but only this one has come to light)

     http://www.mattwrock.com/post/2012/02/29/What-you-should-know-about-running-ILMerge-on-Net-45-Beta-assemblies-targeting-Net-40.aspx

  • Lee Kelleher 4026 posts 15836 karma points MVP 13x admin c-trib
    Feb 21, 2013 @ 10:50
    Lee Kelleher
    0

    @Murray - for me it was the initial release of the WidgetGrid package - was compiled in .NET 4.5 ... I grabbed the source, recompiled against .NET 4.0 and it worked fine. (Then Matt B accepted a pull request and released an update).

    Not sure how to pin-point the culprit DLL ... have you installed any new packages?

    Cheers, Lee.

Please Sign in or register to post replies

Write your reply to:

Draft