1

We have a website, built using the latest MVC 4 running on IIS 7. We created its own application pool and set its runtime version to 4.0. All was going well for the past couple of months. Yesterday, we upgraded to our latest internal version, including other components needed on that machine. One of the components installed Newtonsoft.Json.dll v4.5.10 into the GAC for several of its components.

This broke our website. We did some quick digging and found out that IIS (w3wp.exe) was loading Newtownsoft.Json.dll from the GAC instead of our version from our website (4.5.11 - for .NET 4.0). This is puzzling as we have the application pool set to .NET Framework 4.0.

What would cause IIS to load this DLL from the GAC instead of our local version?

Any way to force it to use our local copy?

They have a high chance of being the same version soon, but one of them is targeting .NET v4.0 instead of v2.0. Any pointers on how IIS handles all this?

I have looked at a couple of thread here and here with no luck.

Community
  • 1
  • 1
Eric Liprandi
  • 5,324
  • 2
  • 49
  • 68

2 Answers2

1

I remember that there is a distinct order of precedence going on with .net libraries.

I dug up this Stackoverflow post that might help your understanding: In what order are locations searched to load referenced DLLs?

In your particular case, might it help if you recompiled your site to use a specific version of the library? (Presumably you're not doing this at the moment?)

Or alternatively you could experiment by putting your version in the GAC as well?

Hope these give you some ideas.

Community
  • 1
  • 1
PeteH
  • 2,394
  • 1
  • 20
  • 29
  • 1
    thanks for the info. I am well aware of the normal loading order for DLLs. However, this is not your run-of-the-mill scenario since IIS is involved. I guess the meat of the question is: Why would an AppPool set to .NET 4.0 be loading a DLL targeting .NET 2.0 instead of a perfectly valid 4.0 one it has in its /bin folder? – Eric Liprandi May 10 '13 at 21:15
1

From what I can tell, Newtonsoft.Json.dll has the same strong name for all versions since 4.5 and across all the different .NET Frameworks it is built for (2.0, 3.5, and 4.0). This wasn't the case back in the 4.0 releases of Json.NET, but as you can read here the versioning strategy changed starting at 4.5. It would be nice if the strong names of the assemblies were different for each targeted .NET Framework, but they're not. As a result, it seems like a crime to put the Newtonsoft.Json.dll in the GAC. It is very likely to break other applications on the machine, especially if the applications are built on a different .NET Framework versions. Since I need to add it to the GAC, I built it myself and changed the strong name.

BuilderBee
  • 132
  • 1
  • 7