Migrating form .NET 4.0 to .NET 4.5, WebApi, NuGet and Co.

Damir Dobric Posts

Next talks:

 

    

Follow me on Twitter: #ddobric



 

 

Archives

Few months ago I tought, I finally survived transition of ASP.NET, WebApi and Co. form VS20010 to VS2012. This was a hard time. Imaging migration of 50 projects in one solution by referencing various version of System.Net.Http, NuGet etc., etc.
This post should archive a few workarounds which might help.

One night mares is error: “Cannot load assembly System.Net.Http …”.

Depending on your current assembly stage (set of referenced assemblies) this error might be caused by various reasons. First this assembly was gaced, then after NuGet has come, Microsoft decided to remove it from GAC and name it by version 2.0.0.0. At the end this assembly is in version 1.0.0.0 which has been rolled out with VS2012, .NET 4.5 and actual NuGet Asp.Net NuGet packages which have been delivered at that time.

If you have this problem, unload your web project and go to edit. Depending on how your project has been created you might find in the project file something like this:

<Reference Include="System.Net.Http />

This referenced assembly is of version 2.0.0.0. You will se that after build process in your bin folder. If you don’t see it in the bin folder it means that the project is pretty old one and expects the Net.Http in GAC.

You should first reference ASP.NET WebApi. The NuGet will do almost everything for you. Everything is meant in term of time which you need to do it by yourself. The only problem with NuGet is that it will not do everything for you and it will let crap of solution. NuGet will ne replace existing references of the same assembly. That means that result of build is 100% fail in such cases. So, if you have assembly A1 already referenced by using some old solution without NuGet and if you add reference to the same assembly by NuGet, the reference will not be replaced in the project file.
Imagine now what happen if you have A1 and NuGet brings you new version of same assembly A1 which now depends on two more assemblies A2 and A3.
As result of adding NuGet reference the project will keep old reference to A1 and add new references to A2 and A3. This will never ever work.
Please feel for a moment the pain of solutions which consist of 50+ such projects.
To workaround this problem by using example of my favorite Net.Http.Dll you will have to do following:

<Reference Include="System.Net.Http, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">

      <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.dll</HintPath>

    </Reference>

    <Reference Include="System.Net.Http.Formatting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">

      <HintPath>..\..\packages\Microsoft.AspNet.WebApi.Client.4.0.20710.0\lib\net40\System.Net.Http.Formatting.dll</HintPath>

    </Reference>

    <Reference Include="System.Net.Http.WebRequest, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">

      <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.WebRequest.dll</HintPath>

    </Reference>

 

You project will probably already contain references to Net.Http or even Formatting, etc. assemblies. Please remove these references, because they caused the pain. 
And please don’t be confused with following. The referenced version of Net.Http is 2.0.20710.

  <package id="Microsoft.Net.Http" version="2.0.20710.0" targetFramework="net40" />

But the file and product versions are 1.0.0.0:

image

Finally, you don’t have to take this seriously. Open it in Reflector and watch. It is 2.0.0.0.

image

Hope this helps a bit.
PS: I remember System Journal articles from 90-tenths, which tried to explain DLL-Hell. Hmmm.

This articles is related to ASP.NET, IIS, SharePoint and Workflow Host Manager technologies. (at lest).


Posted Feb 12 2013, 08:05 AM by Damir Dobric
Filed under: ,
developers.de is a .Net Community Blog powered by daenet GmbH.