Resolving ExtensionAttribute Loading Errors in .NET 4.0: Deep Analysis from ILMerge to Multi-targeting Platforms

Error Phenomenon and Background Analysis

When launching .NET 4.0-based web applications, developers may encounter the following exception:

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

This error typically occurs during application pre-start initialization, particularly when using tools like WebActivator for dependency injection configuration. The stack trace indicates the problem originates from type resolution failure, specifically involving the System.Runtime.CompilerServices.ExtensionAttribute.

.NET Framework Version Compatibility Analysis

ExtensionAttribute has undergone location migration across different .NET framework versions. In .NET 4.0, this attribute was defined in the System.Core.dll assembly, while in .NET 4.5, Microsoft moved it to mscorlib.dll. This migration should have been backward compatible through the TypeForwardedTo attribute, but fails in specific scenarios.

The TypeForwardedTo mechanism works as follows: when a type moves from one assembly to another, a forwarding declaration is added to the original assembly, instructing the runtime to find the type at the new location. Ideally, this mechanism should be completely transparent to applications.

Faults Caused by Improper ILMerge Usage

The most common failure scenario involves incorrect configuration of the ILMerge tool. ILMerge is used to combine multiple .NET assemblies into a single assembly, but when specifying target platforms, using wrong reference assembly paths leads to compatibility issues.

Example of incorrect configuration:

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

When .NET 4.5 is installed on the development machine, assemblies in this directory are actually updated to version 4.5 and are no longer suitable as references for 4.0 projects. The correct configuration should use .NET 4.0 reference assemblies:

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

Build Environment Configuration Essentials

This issue is particularly common in build server environments. Many build servers may not have the Multi-targeting Pack correctly installed, or use unauthorized Visual Studio versions. Developers must ensure build environments use correct reference assembly paths.

The following C# code example demonstrates how to check the current runtime framework version:

using System;
using System.Runtime.Versioning;

class Program
{
    static void Main()
    {
        // Get current framework version
        var framework = AppDomain.CurrentDomain.SetupInformation.TargetFrameworkName;
        Console.WriteLine($"Current target framework: {framework}");
        
        // Check ExtensionAttribute availability
        try
        {
            var type = Type.GetType("System.Runtime.CompilerServices.ExtensionAttribute");
            Console.WriteLine($"ExtensionAttribute type loaded successfully: {type.Assembly.Location}");
        }
        catch (TypeLoadException ex)
        {
            Console.WriteLine($"Type loading failed: {ex.Message}");
        }
    }
}

Solutions and Best Practices

Solutions for this problem include:

1. Update Target Environment: Install .NET 4.5 or later in production environments to ensure runtime environment consistency with build environments.
2. Fix Build Configuration: Check all build scripts and tool configurations to ensure correct reference assembly paths are used.
3. Rebuild Project: Rebuild the project from source code, correcting configuration parameters for ILMerge or other build tools.
4. Verify Dependencies: Check version compatibility of all third-party libraries and tools, particularly those performing assembly merging operations.

For continuous integration environments, it's recommended to configure dedicated build agents to ensure reference assembly correctness. Additionally, explicitly specifying target framework versions in project configuration files can prevent many potential issues:

<Project ToolsVersion="15.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
    <TargetFrameworkProfile>Client</TargetFrameworkProfile>
  </PropertyGroup>
</Project>

Extended Discussion and Preventive Measures

This issue is not limited to ILMerge scenarios. Any situation where .NET 4.5 assemblies are incorrectly referenced in .NET 4.0 projects can cause the same error. Developers should:

• Regularly update multi-targeting packs on build servers
• Clearly document build environment requirements in project documentation
• Use automated testing to verify compatibility across different framework versions
• Consider using more modern frameworks like .NET Standard or .NET Core, which offer better version isolation mechanisms

By understanding differences between framework versions and implementing proper tool configurations, developers can effectively avoid such compatibility issues and ensure stable application operation across different environments.