4

Introduction

today I updated my ASP.NET MVC application and I run into the following error (in german - sorry):

Die Datei oder Assembly "WebGrease, Version=1.5.1.25624, Culture=neutral, PublicKeyToken=31bf3856ad364e35" oder eine Abhängigkeit davon wurde nicht gefunden. Die gefundene Manifestdefinition der Assembly stimmt nicht mit dem Assemblyverweis überein. (Ausnahme von HRESULT: 0x80131040)

(It says that the assembly "WebGrease, Version 1.5.1.25624" could not be found)

The assembly System.Web.Optimization, Version=1.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35 tried to load the WebGrease assembly and failed.

Solution

I know this issue can be easily bypassed by adding a binding redirect in the web.config like so (since I updated WebGrease):

  <dependentAssembly>
    <assemblyIdentity name="WebGrease" publicKeyToken="31bf3856ad364e35" />
    <bindingRedirect oldVersion="0.0.0.0-1.5.2.14234" newVersion="1.6.5135.21930" />
  </dependentAssembly>

Further Question

It would be really nice to know why this is needed and how the *.Optimization assembly is created. The System.Web.Optimization 1.1.3 assembly depends on WebGrease 1.5.2 and a "just take an other version of WebGrease"-redirect could result in method calls, which are not longer existing in the new Version, couldn't it?

Did the developer of *.Optimization include a reference to WebGrease 1.5.2 in their Project, removed the WebGrease assembly after building and created a NuGet package? Or do they load the assembly in code?

Any explanation of how this works is really appreciated. Thank you.

DOK
  • 32,337
  • 7
  • 60
  • 92
CKE
  • 460
  • 3
  • 14

2 Answers2

1

Taken from MSDN doc on this matter:

You can manually edit the app configuration file to resolve assembly issues. For example, if a vendor might release a newer version of an assembly that your app uses without supplying a publisher policy, because they do not guarantee backward compatibility, you can direct your app to use the newer version of the assembly by putting assembly binding information in your app's configuration file.

I also faced this same problem long time ago... anyways I believe this is a problem with the NuGet package as per this work item at CodePlex.

Leniel Maccaferri
  • 100,159
  • 46
  • 371
  • 480
1
  • 1) It is needed to override the entry specified in the manifest of the assembly referencing the offending version of the assembly that cant be found using normal binding policies. (That is, the typical places assemblies are probed for).
    • 1a) There could be breaking changes but one would hope for some kind of tolerant versioning of the assembly in question. Maybe some kind of semantic versioning system.
  • 2) Like Leniel I have faced this problem when downloading assemblies from Nuget. In my experience it has been as a result of an assembly, say C, being required by assemblies A and B but when donwloading assembly B - using Nuget - it has stomped the version of assembly C that A was using. Both confusing and frustrating.
brumScouse
  • 3,166
  • 1
  • 24
  • 38