Could not load file or assembly Microsoft.Extensions.Logging.Abstractions - .net-core

I'm using VS2019 Pro v16.3.5
I have a solution containing an Azure functions project which references several class library projects.
The top-level project fails to compile with the following error:
System.IO.FileNotFoundException: Could not load file or assembly
'Microsoft.Extensions.Logging.Abstractions, Version=2.2.0.0,
Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot
find the file specified.
The project does have a package reference: PackageReference Include="Microsoft.AspNetCore.App" and this framework includes the missing dll, so I don't know why it's having trouble.
My thoughts are perhaps one of the referenced projects is depending on a different version but I don't see it.
I did try explicitly referencing the package in the top-level project but this made no difference:
<PackageReference Include="Microsoft.Extensions.Logging.Abstractions" Version="2.2.0.0" />
Here is a current copy of the top-level csproj file:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp2.2</TargetFramework>
<AzureFunctionsVersion>v2</AzureFunctionsVersion>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.App" />
<PackageReference Include="Base.Core.SharedKernel" Version="1.0.0.23885" />
<PackageReference Include="FluentValidation" Version="8.4.0" />
<PackageReference Include="FluentValidation.AspNetCore" Version="8.4.0" />
<PackageReference Include="MediatR.Extensions.Microsoft.DependencyInjection" Version="7.0.0" />
<PackageReference Include="Microsoft.Azure.WebJobs.Extensions" Version="3.0.2" />
<PackageReference Include="Microsoft.Azure.WebJobs.Extensions.DurableTask" Version="1.8.2" />
<PackageReference Include="Microsoft.Azure.WebJobs.Extensions.ServiceBus" Version="3.0.5" />
<PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.27" />
<PackageReference Include="Newtonsoft.Json" Version="11.0.2" />
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..\Interfaces.Avaloq.Application\Interfaces.Avaloq.Application.csproj" />
<ProjectReference Include="..\Interfaces.Avaloq.Common\Interfaces.Avaloq.Common.csproj" />
<ProjectReference Include="..\Interfaces.Avaloq.Infrastructure\Interfaces.Avaloq.Infrastructure.csproj" />
<ProjectReference Include="..\Interfaces.Avaloq.Persistence\Interfaces.Avaloq.Persistence.csproj" />
</ItemGroup>
<ItemGroup>
<None Update="host.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>
<None Update="local.settings.json">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<CopyToPublishDirectory>Never</CopyToPublishDirectory>
</None>
</ItemGroup>
</Project>
Problems Referencing the Nuget Package
I can see that assemblies for the "working" package references (such as FluentValidation.dll) can be found in the global packages folder at "C:\Users\bowman_rob_a.nuget\packages". However, the global packages folder does not contain v2.2.0.0 of Microsoft.Extensions.Logging.Abstractions, it contains lots of versions but skips from 2.1.0 to 3.0.0.
If I run from the package manager console: "install-package Microsoft.Extensions.Logging.Abstractions -Version 2.2.0" then I get the following error:
The WriteObject and WriteError methods cannot be called from outside
the overrides of the BeginProcessing, ProcessRecord, and
EndProcessing methods, and they can only be called from within the
same thread
Despite the error, the package does then appear in the project's packages section of solution explorer. However, it is listed with a strange path "C:\Program Files\dotnet\sdk\NuGetFallbackFolder\microsoft.extensions.logging.abstractions\2.2.0"
Problems Referencing the Shared Package
Because v2.2.0.0 is included in the shared package reference "Microsoft.AspNetCore.App" then I guess the assembly should be pulled from there? The assemblies for shared packages reside in "C:\Program Files\dotnet\shared." There are lots of versions of the shared package
"Microsoft.AspNetCore.App" but again 2.2.0.0 is skipped, from 2.1.13 to 2.2.4. However, the folder "C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\2.2.4\Microsoft.Extensions.Logging.Abstractions.dll" does contain v2.2.0.0 of the dll.
Version Conflict
I think the root cause of the problem could be that Azure Functions has a dependency on the nuget package chain: Microsoft.Azure.WebJobs.Extensions --> Microsoft.Azure.WebJobs --> Microsoft.Extensions.Logging.Abstractions. The latest version of Microsoft.Azure.WebJobs.Extensions is 3.0.2 and this leads down to v2.1.0 of Microsoft.Extentions.Logging.Abstractions - this is older than the v2.2.0.0 that's included in the Shared Framework Microsoft.AspNetCore.App. Does anyone know how I can change the version of a Shared Framework that's used by the compiler? I can't find a runtimeconfig.json file anywhere!
Work Around
I have been able to make the solution build by removing the Shared Reference from all projects within the solution and adding each required nuget package individually - using the older 2.1.0 versions.

Make sure none of your packages is above the .NET version of the project.
In my case the installed version of Microsoft.Extensions.Http was 5.0 while the project was in .NET Core 3.1. As soon as I downgraded the library to 3.1 everything went smoothly.
Source: https://github.com/Azure/azure-functions-core-tools/issues/2304

Some info and workaround which may help to resolve the puzzle if someone else meets similar issue.
It is listed with a strange path "C:\Program
Files\dotnet\sdk\NuGetFallbackFolder\microsoft.extensions.logging.abstractions\2.2.0"
FallBackFolders are something used to share packages across users and machines to reduce risk space.
They differ from package sources in that the package assets will be referenced directly and will not be copied into the user's packages folder.
That's why you can't find the package in Global Packages like C:\Users\xxx\.nuget\packages.
For Version Conflict
As you mentioned above, the chain of Microsoft.Azure.WebJobs.Extensions is:
Microsoft.Azure.WebJobs.Extensions --> Microsoft.Azure.WebJobs --> Microsoft.Extensions.Logging.Abstractions(2.1.0)
And since you reference the Microsoft.AspNetCore.App package, the chain of it:
Microsoft.AspNetCore.App(2.2.0) --> Microsoft.Extensions.Logging.Abstractions(2.2.0)
I think this could be the cause of the version conflict.You can remove that package to check if it's another workaround.
In addition:
If I create a new Azure Function project in VS16.3.5, we don't need to reference these packages manually:
<PackageReference Include="Microsoft.Azure.WebJobs.Extensions" Version="3.0.2" />
<PackageReference Include="Microsoft.Azure.WebJobs.Extensions.DurableTask" Version="1.8.2" />
<PackageReference Include="Microsoft.Azure.WebJobs.Extensions.ServiceBus" Version="3.0.5" />
<PackageReference Include="Newtonsoft.Json" Version="11.0.2" />
Since Microsoft.NET.Sdk.Functions depends on these packages, nuget will help us downlaod and reference them.
And I tried several kinds of Azure functions project, but none of them need the Microsoft.AspNetCore.App package, so if you don't have specific reason to use that package, you don't need to reference it.

I encountered this issue after upgrading a Nuget package and then reverting. Had to manually delete all bin and obj folders in the solution before it worked again. Cleaning the solution did not help.

I just created a new project using .net 6 and ran into this issue.
I installed entity framework nuget packages:
Microsoft.EntityFrameworkCore.SqlServer
Microsoft.EntityFrameworkCore.Tools
To support data access into a SQL db.
Both of those libraries defaulted to .net 7 for latest version.
These were the errors I was getting:
[2023-01-16T18:15:16.759Z] No job functions found. Try making your job classes and methods public. If you're using binding extensions (e.g. Azure Storage, ServiceBus, Timers, etc.) make sure you've called the registration method for the extension(s) in your startup code (e.g. builder.AddAzureStorage(), builder.AddServiceBus(), builder.AddTimers(), etc.).
[2023-01-16T18:15:16.790Z] The 'Function1' function is in error: Could not load file or assembly 'Microsoft.Extensions.Logging.Abstractions, Version=7.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The system cannot find the file specified.
Even changing the project to .net 7 didn't resolve it, although I wonder if I would have had to update all the nuget packages to 7. I had to downgrade both of those libraries to .net 6 and it compiled and ran fine.
Regardless, I want to remain on 6 with long term support. The only nuisance now is that nuget wants to upgrade those two libraries to .net 7 so they show as available for an upgrade.

I had the same problem in the WebJob project that was compiled in Azure DevOps and running with Azure WebApp.
I have managed to solve the problem by changing "Use .Net Core" task version to the last version (3.1.x) in Build pipeline.
This was the error message :
Unhandled exception. System.IO.FileLoadException: Could not load file or assembly 'Microsoft.Extensions.Logging.Abstractions, Version=5.0.0.0, Culture=neutral, PublicKeyToken=.......'. The located assembly's manifest definition does not match the assembly reference. (.......)

I had a similar issue on running windows service and had to update config file with newly available version by using redirect technique resolved the issue.
<configuration>
<appSettings />
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Extensions.Logging.Abstractions" publicKeyToken="adb9793829ddae60" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-7.0.0.0" newVersion="7.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Extensions.Logging" publicKeyToken="adb9793829ddae60" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-7.0.0.0" newVersion="7.0.0.0" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Microsoft.Extensions.Primitives" publicKeyToken="adb9793829ddae60" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-7.0.0.0" newVersion="7.0.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>

I'm on VS2022 trying to run an httptrigger function of funcapp. I downgraded Microsoft.Extensions.Http from 7.0.0 to 6.0.0 and Microsoft.Extensions.Logging.Abstractions to 6.0.3. This worked fine.

Related

Wix Installer Heat.exe error Parameter "exePath" is invalid

I am building a self-contained .Net Core worker service which I run as a windows service. Now I want to create an installe using Wix, however when I try to harvest all the needed DLL's for installation I get the following error:
An error occurred loading a configuration file: The parameter 'exePath' is invalid.
I've read this post which states the heat.exe might be broken. But I downloaded the tools via NuGet (3.11.2) which should theoretically be fine. My Beforebuild target looks as following:
<Exec Command="dotnet publish ..\Parlando.PVS.PackingSlipService\Parlando.PVS.PackingSlipService.csproj -c $(Configuration) -r win10-x86" />
<ItemGroup>
<LinkerBindInputPaths Include="%(ProjectReference.RootDir)%(ProjectReference.Directory)bin\$(Configuration)\%(ProjectReference.TargetFrameworkIdentifier)\win10-x86\publish" />
</ItemGroup>
<HeatDirectory
DirectoryRefId="INSTALLFOLDER"
OutputFile="$(ProjectDir)\HeatGeneratedFileList.wxs"
Directory="..\Parlando.PVS.PackingSlipService\bin\Release\netcoreapp3.1\win10-x86\publish"
ComponentGroupName="HeatGenerated"
ToolPath="$(WixToolPath)"
AutogenerateGuids="True"
SuppressCom="True"
SuppressRegistry="True"
SuppressFragments="True"
SuppressRootDirectory="True"
NoLogo="true" />
<ItemGroup>
<Compile Include="$(ProjectDir)\HeatGeneratedFileList.wxs" Condition="'%(ProjectReference.IsDotnetSDKProject)' == 'True'" />
</ItemGroup>
This should generate a .wxs file that I reference in the Product.wxs file when installing the service. My product.wxs does so as followed:
<ServiceInstall
Id="ServiceInstaller"
Type="ownProcess"
Name="Parlando.PVS.PackingSlipService"
DisplayName="Parlando.PVS.PackingSlipService"
Description="Service installed by Parlando to create packingslips and invoices."
Start="auto"
Account="LocalSystem"
ErrorControl="normal" />
<ServiceControl
Id="ServiceInstaller"
Start="install"
Stop="both"
Remove="uninstall"
Name="Parlando.PVS.PackingSlipService" />
</Component>
<ComponentRef Id="HeatGenerated" />
How can i use the heat.exe in such a way that I can access the DLL list in my Product.wxs and install my service via MSI?
Apperantly this error has nothing to do with the provided settings for the Wix installer, but rather the machine that Wix is installed on.
After testing my program on a different machine, all worked fine.

Generating Nuget package on build does not include all dependencies

The tree of my solution looks like :
Project A
References Nuget Package "Some Package"
Project B
References Project A
When building, project B produces a package, let's call it PackageB
In ProjectB.csproj I have used the following:
<ProjectReference Include="ProjectA.csproj">
<PrivateAssets>All</PrivateAssets>
</ProjectReference>
Meaning PackageB, in addition to ProjecdtB.dll, includes ProjectA.dll
However it does not include "Some Package", so when I launch a client that references PackageB, I get a runtime error complaining that the dll contains in "Some Package" is missing.
How can I make sure "Some Package" is added as a depencency of PackageB. I'd like to do this in csproj, without relying on a nuspec file. Is this possible ?
[EDIT]
In order to get ProjectA included in the PackageB, I also need to mention that I'm using the Teronis.MSBuild.Packaging.ProjectBuildInPackage.
Thanks for using my package.
Let's first assume the following:
<!-- Project A -->
<ItemGroup>
<PackageReference Include="SomePackage" Version="*" />
</ItemGroup>
<!-- Project B -->
<ItemGroup>
<ProjectReference Include="ProjectA" PrivateAssets="all">
<!--<PackageReference Include="Teronis.MSBuild.Packaging.ProjectBuildInPackage" Version="0.1.7" />-->
</ItemGroup>
You are telling NuGet that you don't want to have Project A to be picked up as NuGet-dependency. This is implicit, you don't have control about that. The down-side is the assmeblies of Project A, but not the assemblies of the packages of Project A, are not present in package of Project B.
By removing PrivateAssets="all" you disable the implicit behaviour of NuGet and the Project A will be picked up as NuGet dependency and EACH non-dependency package (also called transitive package).
Now let's asumme this:
<!-- Project A -->
<ItemGroup>
<PackageReference Include="SomePackage" Version="*" />
</ItemGroup>
<!-- Project B -->
<ItemGroup>
<ProjectReference Include="ProjectA" PrivateAssets="all">
<PackageReference Include="Teronis.MSBuild.Packaging.ProjectBuildInPackage" Version="0.1.7" />
</ItemGroup>
By having installed my package I assist in the implicit behaviour of NuGet: By not picking up Project A as NuGet-dependency copy over the direct assemblies produced by Project A to the bin-folder of Project B. This has the following drawback:
Because of the implicit behaviour and the usage of my package you have assemblies of Porject A in Project B that are in need of the assemblies provided by packages (in your example "Some Package") you referenced in Project A. So a workaround is to add the packages from Project A in Project B explicitly as shown here:
<!-- Project A -->
<ItemGroup>
<PackageReference Include="SomePackage" Version="*" />
</ItemGroup>
<!-- Project B -->
<ItemGroup>
<ProjectReference Include="ProjectA" PrivateAssets="all">
<PackageReference Include="Teronis.MSBuild.Packaging.ProjectBuildInPackage" Version="0.1.7" />
<!-- Use the SAME version like in Project A. -->
<PackageReference Include="SomePackage" Version="*" />
</ItemGroup>
This should solve your problem. Please provide feedback when it does NOT work.
In the PackageReference documentation, PrivateAssets is described as:
These assets will be consumed but won't flow to the parent project
Meaning the dependencies of Project A won't be copied over in Package B.
If you remove the PrivateAssets node, it should flow the dependencies properly.

Referencing assemblies under dotnet installation directory

Wondering if there is any legitimate reason for a .csproj to contain an assembly reference to an assembly w/ a hint path under the dotnet installation directory (default: c:\Program Files\dotnet on Windows).
In particular, the directories
packs
sdk
shared
An example of such a reference:
<ItemGroup>
<Reference Include="Microsoft.Extensions.Configuration.Abstractions">
<HintPath>..\..\..\Program Files\dotnet\packs\Microsoft.AspNetCore.App.Ref\3.1.0\ref\netcoreapp3.1\Microsoft.Extensions.Configuration.Abstractions.dll</HintPath>
</Reference>
</ItemGroup>
Surely not. This application would not work on other machines.
It looks like someone inserted code that uses Microsoft.Extensions.Configuration.Abstractions package which was not referenced and then probably applied "Quick fix" action from Resharper/Rider. Sometimes it leads not to referencing Nuget package
<ItemGroup>
<PackageReference Include="Microsoft.Extensions.Configuration.Abstractions" Version="3.1.1" />
</ItemGroup>
but to referencing locally placed assembly.

Dotnet publish with .NET core 2.0 and .NET framework projects

I'm hoping someone has some advice on the best way to use Teamcity to build and publish a solution that has both .NET Core/standard 2.0 projects and .NET framework 4.6.x projects in it.
Currently, I can build the project, run tests, but I can't figure out a way to publish it via the dotnet-cli. We have a relatively large solution, approximately 75 projects in .NET core/standard and 5 or some framework projects. Running dotnet publish on our solution results in the following error on the .NET framework projects:
error: C:\Program Files\dotnet\sdk\2.0.3\Microsoft.Common.CurrentVersion.targets(3861,5): error MSB4062: The "Microsoft.Build.Tasks.ResolveManifestFiles" task could not be loaded from the assembly Microsoft.Build.Tasks.Core, Version=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
It would be ideal if the cli could attempt to ignore publishing the .NET Framework projects, but it doesn't seem to be possible. I'm thinking about writing a powershell script to check all csproj files in our solution for an appropriate TargetFramework value (i.e netstandard2.0/netcoreapp2.0), and publish them individually, but maybe someone knows a better way?
If anyone is facing the same issue, you need to restructure your csproj file as suggested by #nvoigt.
You can follow the steps as described in the post Old csproj to new csproj
You can start clearing out your csproj file and start with below format.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net462</TargetFramework> // if your target is 4.6.2
</PropertyGroup>
</Project>
And now you can add remaining of your dependency like below.
...
<ItemGroup>
<PackageReference Include="Dapper" Version="2.0.4" />
<PackageReference Include="Microsoft.Azure.Storage.Blob" Version="11.1.1" />
<PackageReference Include="Microsoft.Extensions.Configuration" Version="3.0.0" />
<PackageReference Include="Microsoft.Extensions.DependencyInjection" Version="3.0.0" />
<PackageReference Include="Microsoft.Extensions.Logging" Version="3.0.0" />
<PackageReference Include="Microsoft.Azure.KeyVault" Version="2.0.6" />
<PackageReference Include="NLog" Version="4.7.5" />
<PackageReference Include="NLog.Extensions.Logging" Version="1.6.5" />
</ItemGroup>
...
you can find more details on the post.

Could not load file or assembly 'System.Net.Http, Version=2.0.0.0 in MVC4 Web API

I have a bit of a weird problem.
I developed an app with MVC 4 and the new Web API and it works fine locally.
I installed MVC4 on the server and deployed the app. Now I get the following error:
Could not load file or assembly 'System.Net.Http, Version=2.0.0.0, 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)
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in
Funny enough, the version of System.Net.Http that I locally have either in my package folder or in the ASP.NET MVC 4\Assemblies folder is 1.0.0.0.
I actually removed the reference to System.Net.Http from my project, but I still get the same message. I'm a bit confused about where it gets the 2.0.0.0 reference from and why it would work locally but not on the server.
Looking at the nuget dependencies:
ASP.NET WEb API Core Libraries (Beta) depends on System.Net.Http.Formatting.
And System.Net.Http.Formatting depends on System.Net.Http.
I guess that is where this comes from. But I do have Version 2.0.20126.16343 of this package installed, it's just that the dll inside has version 1.0.0.0
Am I missing something?
UPDATE:
This is a sub-application of another ASP.NET app, but the other one is still based on WebForms. So, something is getting messed up. But if I do a clean under the assembly section in the web.config if does not even find the app itself anymore.
I had the same error while deploying previously converted (from .NET 4.5 to 4.0) web app on IIS 6.0.
In the web.config runtime section I've found
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.0.0.0"/>
</dependentAssembly>
which I've changed to
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-1.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>
Now works like charm.
I had the same problem with deployment my app to appharbor. The problem it does not support .NET 4.5 yet. What I did.
Switched my project to .NET 4.0 profile.
Uninstalled Web API NuGet package.
Installed Web API (Beta) NuGet package again.
Verified that .csproj file contains for ALL referenced assemblies, so it will always take it from Bin folder, instead of GAC.
Mine worked with:
Note the redirect of 1-4 to 2.0
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>
In your project's References folder there should be a reference to this dll, and the version should be 2.0.0.0. Make sure this is set to Copy Local = true. And then make sure it finds its way to your server app's bin folder.
This is one of the libraries that is now managed by nuget. So open Nuget and make sure everything is up to date. And in your projects packages directory the file should be here:
\packages\System.Net.Http.2.0.20126.16343\lib\net40
You could also try creating a new MVC4 app and see if the file shows up for that one.
In my case I fixed it in a much easier way, just give a HintPath to the reference to the nuget package:
<Reference Include="System.Data.Entity" />
<Reference Include="System.Net.Http, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<Private>True</Private>
+ <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.dll</HintPath>
</Reference>
<Reference Include="System.Net.Http.WebRequest, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<Private>True</Private>
+ <HintPath>..\..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.WebRequest.dll</HintPath>
</Reference>
<Reference Include="System.Numerics" />
<Reference Include="System.Security" />
In my case I unintentionally added a dependency to System.Net.Http version 2.1.10.0 through NuGet. I couldn’t get rid of it in the NuGet Package Manager (because other packages seemed to be dependent on it). However those packages aren’t dependent on this particular version.
Here's what I did in order to get rid of it (you can also use the NuGet console instead (using the –force parameter):
Change version of Microsoft.Net.Http in packages.config from 2.1.10.0 to 2.0.0.0
Uninstall BCL Portability Pack in NuGet Package Manager
Manually get rid of dependent libraries (System.Net.Http.* which have version 2.1.10.0)
Add a reference to System.Net.Http 2.0.0.0
In file config I deleted dependent Assembly:
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
<dependentAssembly>
Now it works fine.
I was facing this issue on a test server (Windows 2008 R2) which was supposedly "ready" for deployment ;)
The hint was that when I checked the versions of System.net between my DEV machine and deployment server, they did not match.
Fixed using the steps below:
Downloaded .NET Framework 4.5 Standalone installer from HERE
Ran the installer on the deployment machine
Post installation of the framework, server wanted a reboot, so did that and volla! We are good to go!!
We are using VS 2013, created a new MVC 4 Web API and had a problem with the system.net.http.dll not being the correct version when built on our TeamCity server but it builds fine on our local developer machines that have VS 2013 installed.
We finally determined the problem.
When creating a new MVC 4 Web API and choosing the framework 4.0 on project creation we found the the correct NuGet package version for DLL was being put in:
..\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.dll
However the .csproj file for this project said the path for this system.net.http.dll file is:
..\packages\Microsoft.Net.Http.2.0.30506.0\lib\net40\System.Net.Http.dll
So when the build is attempted is fails on this path difference but is finding the correct framework version of the file elsewhere on the developer machine but not on our TeamCity build server.
So far this is the only difference we found. Changing the path in the .csproj file and building on local Dev machine with VS2013 still works find.
Checking that into version control and having our TeamCity build server (without VS 2013 installed locally) now finds the correct version of the .dll in its NuGet package folder for the solution and builds successfully rather than searching for another version of system.net.http.dll and finding a newer version which doesn't match the framework hence causing build failures.
Not sure if this helps.
Check your project file path for the DLL and make sure it matches your package folder path for the DLL.
Just simplifying the other answers for what worked for me.
I went to the NuGet manager, uninstalled the related packages (In my case, "Microsoft ASP.NET Web API 2.1 Client Libraries" and "Json.NET") and reinstalled them. Just took a few clicks.
Close the project, Open it again. Then, Clean Solution + Build. Works for me
For version 2.2.15.0, I did this:
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.2.15.0"/>
</dependentAssembly>
I had this exact same issue! I took a look at my Warnings tab in VS and noticed that one of my nuget packages was INDIRECTLY referencing .NETFramework Version 4.5.0.0. I had to uninstall this package and then reinstall the 4.0 version but be sure to specify the package versions that support 4.0(it'll default back to 4.5 i believe if you don't specify when installing the package). Hope this helps!
We had this happening on a server after deployment. It was caused either by:
A) Old files in the bin folder still hanging around that ought to have been deleted
or
B) Not having read access to the folder for the Application Pool Identity user.
In other words, for us this was resolved by fixing permissions on the folders for the site and wiping out the bin folder and redeploying.
I had the same issue with Gembox.spreadsheet.dll version 31.
" Could not load file or assembly 'GemBox.Spreadsheet,
Version=39.3.30.1095, Culture=neutral,
PublicKeyToken=b1b72c69714d4847' or one of its dependencies. The
located assembly's manifest definition does not match the assembly
reference. (Exception from HRESULT: 0x80131040) "
I tried almost everything from these articles and none of them worked. It just got fixed with simple step.
I tried building individual projects that basically set up the correct version reference to the dll and the error was entirely gone from the solution.
Go a similar issue and the directive mentionned in many comments worked fine
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="2.0.0.0"/>
<dependentAssembly>
Although, you have to ensure the old version coverage is high enough otherwise newer versions may not be redirected to the specific version you need and location using that newer reference won't work properly since the older reference is already in the bin directory.
For this error (and similar) it's worth going through NuGet Consolidate (Solution > Manage NuGet Packages...) to ensure the same referenced component versions are consistent in each class library referenced in the solution, since even a slightly older version may have dependencies on other older components. It's straightforward to use in conjunction with Updates and can save a lot of pain.
This solved this issue for me and I would say it's a must to get familiar with if you're creating helper libraries that also reference MVC or other web-based NuGet components.

Resources