New DLL Hell; wrong build version

Question

I am running VS2013 1 update using Nuget v 2.8.50313.46

You can go to , this is an important bit , as well as some recent updates and return to the link.

I have a VS solution, this is a simplified view.

-- Solution - Base (Class Library) Packages: No Packages Installed. References: System System.Configuration System.Core System.Runtime.Caching System.Web - AppBase (Class Library) Packages: No Packages Installed. References: System System.Core System.Web.Http Base - Client (Console Application) Packages: EntityFramework v6.1.0 HtmlAgilityPack v1.4.6 References: EntityFramework EntityFramework.SqlServer HtmlAgilityPack System System.Core AppBase Base - Server (Web Application) Packages: HtmlAgilityPack v1.4.6 Microsoft.AspNet.WebApi v5.1.2 Microsoft.AspNet.WebApi.Client v5.1.2 (dependent on > Newtonsoft.Json v4.5.0) Microsoft.AspNet.WebApi.Web... v5.1.2 Newtonsoft.Json v6.0.3 References: HtmlAgilityPack Newtonsoft.Json System System.Net.Http System.Net.Http.Formatting System.Web System.Web.Http System.Web.HttpHost AppBase Base 

The code inside the Server needs the Newtonsoft.Json v6.0.3 function.

When I rebuild everything and start everything works fine, as expected.

Subsequently, I only AppBase without building a Server . AppBase depends only on Base . The binaries for AppBase and Base are "up to date" as expected.

However

this is an important bit

building an AppBase causes AppBase be replaced in the "Server \ bin" folder for an earlier version 4.5.

When I make a request to Server , the "Internal Server Error 500" error is returned due to a binding error caused by the incorrect version of Newtonsoft.Json dll.

Why does building an assembly affect an independent assembly?

Has anyone else experienced this?

What is the best way to solve this problem?

---

EDIT 06/19/2014

I created a new solution file, first I decided that this solved the problem. However, the problem was ported to System.Net.Http.Formatting.dll : -S

If I edit AppBase , so it does not reference System.Web.Http , the effect will disappear. Maybe this has something to do with the MVC material in the Program Files? ...

---

EDIT 06/20/2014

I posted a wiki community response detailing how I worked on the issue. I thought someone might find this helpful. However, the workaround does not explain what Server does when I build only AppBase and Base . Does this sound like an error, it seems wrong?

Answer 1

The link to System.Web.Http in AppBase pointed to

C: \ Program Files (x86) \ Microsoft ASP.NET \ ASP.NET MVC 4 \ Assemblies \ System.Web.Http.dll

I added my last

 Microsoft.AspNet.WepApi.Core 5.1.2 

before AppBase , as used in Server . This pulled dependency packages,

 Microsoft.AspNet.WebApi.Client 5.1.2 Newtonsoft.Json 6.0.3 (the only version in my package source) 

The System.Web.Http link in AppBase now points to,

MySolutionFolder \ packages \ Microsoft.AspNet.WebApi.Core.5.1.2 \ Lib \ net45 \ System.Web.Http.dll

When I create AppBase now, the WepApi DLL in Server will no longer be changed to legacy versions.

---

By the way

This package change adds several (a|A)pp.config to solution projects, all with redirecting bindings to the latest version of Newtonsoft.Json .

---

Note

I really see it as a job, although I'm glad to find one.

The AppBase code really does not need the latest System.Web.Http.dll . I still don’t know why the creation of AppBase should work Server , is this a mistake?

Marking problematic DLLs as read-only did not protect them. A change in security rights was performed, but an AppBase not recorded during the assembly of AppBase , even when writing a diagnostic log.

Answer 2

Nuget installs the selected package and any other packages on which it depends. Obviously, in your server solution there are packages using Newtonsoft.Json v4.5, so Nuget copies the DLL to bin, there is a problem.

You can use call forwarding redirects , as Jon Skeet commented, or you should use Newtonsoft.Json v4.5 in the server solution.

Another option is extern alias to reference two different versions of this DLL.

Answer 3

I suspect that the problem you are facing is related to the package cache of your solution.

Try the procedure as described in Jordan Walter's answer in this post