Could not load file or assembly 'WebGrease' one of its dependencies. The located assembly's manifest definition does not match the assembly reference

Question

This issue has many solutions, please read all answers below, they might help you solve your problem too. If you find a new way to solve this, please document in your answer

I am trying to add System.Web.Optimization to my ASP.NET Web Forms solution. I added Microsoft ASP.NET Web Optimization Framework through NuGet Packages. It added Microsoft.Web.Infrastracture and WebGrease (1.5.2) to the references.

However, when I run

<%= System.Web.Optimization.Scripts.Render("~/bundles/js")%>

I get runtime error

Could not load file or assembly 'WebGrease, Version=1.5.1.25624, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

I have tried adding assemblyBinding to the Web.Config

<runtime>
  <legacyUnhandledExceptionPolicy enabled="1"/>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="WebGrease" publicKeyToken="31bf3856ad364e35" culture="neutral"/>
        <bindingRedirect oldVersion="0.0.0.0-1.5.1.25624" newVersion="1.5.2.14234"/>
      </dependentAssembly>
    </assemblyBinding>
</runtime>

But without any luck.

I noticed that my WebSite's Web config contains this line

 <configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">

If I replace it with

 <configuration>

Then everything works and I don't get the runtime error. Unfortunately, I need the xmlns. Other components of my project depend on it.

Why would Optimization try to load an older version when schema is pointing to v2.0? Is there a way to force it to load the latest or the only available WebGrease.dll?

What else can I try without changing the

 <configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0"> ?

Thank you for any help you can provide!

Edit: 1) Attaching FusionLog Result. Maybe it will be helpful

=== Pre-bind state information ===
LOG: User = [USER]
LOG: DisplayName = WebGrease, Version=1.5.1.25624, Culture=neutral, PublicKeyToken=31bf3856ad364e35
(Fully-specified)
LOG: Appbase = file:///C:/Projects/PROJECT_NAME/trunk/www.PROJECT_NAME.com/
LOG: Initial PrivatePath = C:\Projects\PROJECT_NAME\trunk\www.PROJECT_NAME.com\bin
Calling assembly : System.Web.Optimization, Version=1.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: C:\Projects\PROJECT_NAME\trunk\www.PROJECT_NAME.com\web.config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: WebGrease, Version=1.5.1.25624, Culture=neutral, PublicKeyToken=31bf3856ad364e35

2) Confirmed, The issue is in

<configuration  xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">

However, I don't understand why

Answer 1

I met this issue on a prod server, while everything worked fine on developer machine. These lines helped:

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="WebGrease" publicKeyToken="31bf3856ad364e35" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-1.5.2.0" newVersion="1.5.2.14234"/>
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

Answer 2

Finally, the issue was in <configuration xmlns="http://schemas.microsoft.com/.NetConfiguration/v2.0">. It caused the Render method to load wrong WebGrease assembly.

Removing the xmlns solved the issue for me.

Answer 3

I modified my web.config file so that the newVersion="1.0.0.0" matched my Referenced file version:

<dependentAssembly>
    <assemblyIdentity name="WebGrease" publicKeyToken="31bf3856ad364e35" />
    <bindingRedirect oldVersion="1.0.0.0-1.3.0.0" newVersion="1.0.0.0" />
  </dependentAssembly>

Answer 4

Just in case it helps anybody, I had the same issue, but found it was caused by a dependent assembly of WebGrease, namely Antlr3. It had added the following to runtime element in web.config when installing via NuGet:

  <dependentAssembly>
    <assemblyIdentity name="Antlr3.Runtime" publicKeyToken="eb42632606e9261f" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.5.0.2" newVersion="3.5.0.2" />
  </dependentAssembly>

Simply removing this fixed my issue.

Answer 5

met the same issue in web forms site .net 4.5 simple update nuget packages to last version helped me.

Answer 6

In my case, the problem turned out to be an XML Processing Instruction (PI) (<?blah ... ?>) in my web.config file. Perfectly legal XML! but it caused this error message to show up and had me looking in all the wrong places.

My web.config looked similar to the following - note the XML PI in the connectionStrings section:

<configuration>
    ...
    <connectionStrings>
        <?blah ... ?>
        <add name="AppDb" ... />
    ...
    </connectionStrings>
    ...
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            ...
            <dependentAssembly>
                <assemblyIdentity name="WebGrease" publicKeyToken="31bf3856ad364e35" />
                <bindingRedirect oldVersion="0.0.0.0-1.5.2.14234" newVersion="1.5.2.14234" />
            </dependentAssembly>
            ...
        </assemblyBinding>
    </runtime>
    ...
</configuration>

Note that the XML PI <?blah ... ?> was in the connectionStrings section -- that is, nowhere near the assemblyBinding section, or the bindingRedirect entries for WebGrease etc (which were correct!).

Answer 7

I had this same issue but it was the result of copying a solution from my local development computer to a networked drive where we store our projects. I was unable to get the reference to work properly when I opened the solution from a mapped drive and I kept receiving this error. Only temporary workaround I found for my specific issue was to open the solution from its UNC path and not the mapped drive letter.