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

8

20

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

Stake answered 3/1, 2014 at 17:2 Comment(0)
S
17

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.

Stake answered 13/1, 2014 at 19:15 Comment(3)
Your solution works very fine. Can someone tell me why?Undecided
I would love to know why this breaks my project, because that line is required in the top level of my web.config for my web.testing.config to actually replace the connection string. Removing it fixes my project, but at the same time stops my transformations.Earwig
I read the various answers, tried a few of them, and no luck until I removed the xmlns reference as shown in this answer.Kilpatrick
L
29

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>
Lighthouse answered 6/5, 2014 at 2:50 Comment(5)
This has saved me at least twice now, as I realized when I went to go upvote you again. Any idea why the wrong version would be referenced only on my prod server, like you? The correct version seems to be referenced in VS via NuGet. Thanks =)Verst
Need to check the Fusion log. May be a machine-wide config contains a redirect rule on a dev PC.Lighthouse
Interesting, if xmlns="urn:schemas-microsoft-com:asm.v1" would have been a fix in my case too. Unfortunately, I don't have the access to the code from my question anymore.Stake
Thanks for your answer. Just got the same problem right now while deploying an MVC 4 app for the first time on a clean WS 2008 / IIS 7.5. I don't know from what this behavior comes as I just applied the fix without to do the fusion log / machine.config checks stuff but it looks like to come with some version of .Net and other components, even if the configuration files and GAC default libraries are pristine of any manual changes...Ampereturn
By mistake i excluded the WebGrease.dll file from project and faced same problem, solved by including it to project.Lighterman
S
17

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.

Stake answered 13/1, 2014 at 19:15 Comment(3)
Your solution works very fine. Can someone tell me why?Undecided
I would love to know why this breaks my project, because that line is required in the top level of my web.config for my web.testing.config to actually replace the connection string. Removing it fixes my project, but at the same time stops my transformations.Earwig
I read the various answers, tried a few of them, and no luck until I removed the xmlns reference as shown in this answer.Kilpatrick
Q
6

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>
Quay answered 25/3, 2014 at 17:6 Comment(4)
I have tested using your approach, unfortunately it didn't do the trick for me. In my case, it's the xmlns that breaks it.Stake
Works for me as well. Just make sure you change the newVersion above to match your DLL. In my case it was <bindingRedirect oldVersion="1.0.0.0-1.6.0.0" newVersion="1.3.0.0" />Aubyn
i had to remove the entire webgrease dependantAssembly block to et rid of this for meStepha
It's been a while since I had to implement this solution, so I don't remember specifically what settings are responsible, but I believe that newVersion="...." needs to match the package version the oldVersion="..." needs to include the new version in its range... but has to be compatible .......????Quay
L
5

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.

Littman answered 14/11, 2016 at 11:25 Comment(0)
T
2

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!).

Tottering answered 22/1, 2018 at 19:3 Comment(0)
S
1

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

Shielashield answered 11/1, 2017 at 8:25 Comment(0)
S
1

I ended up with 2 runtime assemblyBinding entries for WebGrease. Deleting the older one (version 1.5.2) solved my issue.

<dependentAssembly>
    <assemblyIdentity name="WebGrease" publicKeyToken="31BF3856AD364E35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-1.5.2.14234" newVersion="1.5.2.14234" />
</dependentAssembly>

<dependentAssembly>
    <assemblyIdentity name="WebGrease" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-1.6.5135.21930" newVersion="1.6.5135.21930" />
</dependentAssembly>
Subconscious answered 31/12, 2019 at 21:5 Comment(0)
V
0

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.

Valida answered 28/3, 2016 at 16:34 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.