Well I have a problem, we upgraded the .net framework from version 4.0 to version 4.6 of .net, I have about 9 projects running and I had to install masstransit and autofac in 2 projects, this caused some libraries to be updated or installed in other projects.
At the moment in one of the projects(Team.Services) I have installed the 4.5.2 version of the library System.Threading.Tasks.Extensions, before of this I had the version 4.2.0.0, but now I update this. The image below you can see that it is version 4.5.2.
Now when I see the references of the project I can see that I do not have the correct version referenced, it is as if another dll was installed
look for the solution(link below) in other places, also try to change the version in the app.config check the version in the package.config clear the nuget cache and reinstall everything. and it is not working, it keeps looking for the old dll and for this reason it doesn't find the new dll, besides the installations seem to be a different version.
DLL hell - Could not load file or assembly System.Threading.Tasks.Extensions
This is the error:
System.IO.FileNotFoundException
HResult=0x80070002
Message=Could not load file or assembly 'System.Threading.Tasks.Extensions, Version=4.2.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.
Source=Team.Services
StackTrace:
at Team.Services.ServiceFactory.StartServices(String applicationDirectory) in C:\Users\amilkar.contreras\source\repos\TFS.TeamServices\Common\Team.Services\ServiceFactory.vb:line 110
at Team.ServiceHost.Service.OnStart(String[] args) in C:\Users\amilkar.contreras\source\repos\TFS.TeamServices\Hosts\TeamServiceHost\Service.vb:line 25
at Team.ServiceHost.Service.Start(String[] args) in C:\Users\amilkar.contreras\source\repos\TFS.TeamServices\Hosts\TeamServiceHost\Service.vb:line 34
at Team.ServiceHost.Program.Main(String[] args) in C:\Users\amilkar.contreras\source\repos\TFS.TeamServices\Hosts\TeamServiceHost\Program.vb:line 41
You can have a try the possible solution to solve it:
Confirm the Package Management is Package.config in visual studio, then reinstall this package again
delete .vs folder then restart visual studio
Remove this dll manually, then add the new dll as reference manually
I have legacy code that is currently building and running in Visual Studio 2013 Pro with .NET Framework 4 as expected. This C# code is in a single file and references a single .dll (VmfgInventory.dll) from a third party. The dll is added as a reference in the project.
I created a new project in Visual Studio 2019 Community Ed. Then copied the C# file from the VS2013 Pro project into the VS2019 Comm project. Next, I added copied the VmfgInventory.dll from the bin\Debug directory of VS2013 and added it to the bin\Debug directory of VS2019 and added it as a reference.
I then executed the exact same code in VS2019 and it crashes. I receive the following System.IO.FileNotFoundException
Message "Could not load file or assembly 'Microsoft.Vsa, Version=7.0.5000.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified."
I don't understand it, it's the exact same development machine. I've looked all over my machine and the only thing that I can find that matches Microsoft.Vsa is a version 8 of this dll that is under .NET Framework 2.
What could I possibly be overlooking? What allows the same code and referenced dll to work in VS2013 but not in VS2019?
We are developing a .NET windows application and decided to use ClickOnce instead of just copy/paste files from release folder.
After deployed and installed on user machine, we started to have the following error:
System.IO.FileNotFoundException: Could not load file or assembly System.Net.Http, Version=4.1.1.2, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
We saw that this file was not being deployed together with the application and found this Question Deploying System.Net.Http.dll with ClickOnce but says microsoft would solve the problem. We are using VS2017 and seems like the same result.
Could not find what to do to fix this without a workaround. Does anyone know how to fix?
You can remove the reference that points to C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.X.X\System.Net.Http.dll and simply add the System.Net.Http NuGet package.
This will be deployed without problem.
I wrote a small C#/WPF application that builds a list of solutions with MSBuild.
These solutions can easily be built with Visual Studio 2017.
However, if I build the same solutions with MSBuild, I get the following error:
The "Microsoft.CodeAnalysis.BuildTasks.Csc" task could not be loaded
from the assembly C:\Program Files (x86)\Microsoft Visual
Studio\2017\Professional\MSBuild\15.0\Bin\Roslyn\Microsoft.Build.Tasks.CodeAnalysis.dll.
Could not load file or assembly 'Microsoft.Build.Utilities.Core,
Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or
one of its dependencies. The system cannot find the file specified.
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.
What is striking here is that version 14.0.0.0 is being searched for, although Visual Studio 2017 and version 15.0 are being used.
To narrow down the problem, I build a simple C# console application that only outputs a Hello World string. But I get the same error message.
I have the following constellation:
Visual Studio 2017
NuGet packages: Microsoft.Build, Microsoft.Build.Framework, Microsoft.Build.Tasks.Core and Microsoft.Build.Utilities.Core version 15.9.20 and Microsoft.Net.Compiler version 2.10.0.
I read here that
The Microsoft.Net.Compilers package overrides (by setting properties
in your project file) the default version of Roslyn included with
MSBuild / Visual Studio.
A downgrade of the Microsoft.Net.Compiler to version 2.8.2 as suggested here does not change the bug.
How can I make sure that I build with the right version?
Visual Studio is overwriting the correct version of NewtonSoft.Json.DLL that I have configured in both my project references and the NuGet package file with an older version when I build any other project besides the website that contains the reference.
OK. Here is the scenario:
I have a solution with a backend service and a website. The website is running on .NET 4.5 and is configured with NuGet to pull in version 6.0.1 of Newtonsoft.Json.DLL.
<package id="Newtonsoft.Json" version="6.0.1" targetFramework="net45" />
Which adds the dependenAssembly binding to the web.config file.
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
</dependentAssembly>
I can build and run this website without any problems.
I recently updated all of the class libraries and backend service from .NET 4.0 to .NET 4.5. After the update, whenever I build one of the class libraries or run/debug the backend service, the website becomes inoperable.
Could not load file or assembly 'Newtonsoft.Json' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I tracked this down to the fact that when rebuilding one of the class libraries or running/debugging the backend service from Visual Studio, the Newtonsoft.Json.DLL gets overwritten with an older version of the file - version 4.5.11. Because of the explicit dependentAssembly binding, any time I access the website after that I get the 'Could not load ...' error mentioned above.
This would be OK if I just wanted to run one or the other of the backend service or the website, but I have to run them both together to get my application running properly. But because of this error I cannot have the backend service running at the same time as the website or the website crashes.
How do I prevent Visual Studio from overwriting the DLL?
Note that I have the reference set for only 6.0.1 across the entire solution (i.e. there is no reference anywhere to 4.5.11). And in the website I have 'Copy Local' set to true and 'Specific Version' is also set to true for the Newtonsoft.Json.DLL.
This is a known bug in Windows Azure VS Tools
Workarounds:
Remove Newtonsoft.Json.dll file from Program Files\Microsoft
SDKs\Windows Azure.NET SDK\v2.3\ref\ folder.
Uninstall Windows Azure VS Tools v 2.3
The Problem
Your csproj contains a reference with an invalid path to the Newtonsoft.Json dll. In my case, it was
<HintPath>..\..\packages\Newtonsoft.Json\lib\net45\Newtonsoft.Json.dll</HintPath>
instead of the one NuGet should have set, packages\Newtonsoft.Json.8.0.3\... (incl. version number).
Since VS cannot find the dll, it will just search on your system, and use the first one it finds. On my system, that was Azure SDK 2.9, then Azure SDK 2.8, then VS12/Blend/....
The Solution
Some of the solutions above (deleting all Newtonsoft.Json.dlls you find in your system) might hide the problem in the short-term, but only fixing the csproj to point to the correct NuGet-supplied path will really solve the issue.
That is, make sure the HintPath in your csproj corresponds to the package path where the NuGet package is installed.
If you have bash, you can use
$ grep -r HintPath * | grep Newtonsoft
in the root directory of your solution to find the offending csproj.
Related errors
If you have this problem, starting your Asp.Net site with the explicit redirect in web.config might fail with an exception page, with the following text in the error message:
LOG: Attempting download of new URL newtonsoft json
WRN: Comparing the assembly name resulted in the mismatch: Major Version
Even if some projects have a reference to the NuGet of Newtonsoft.Json 8.x, VS will happily compile, then overwrite that DLL with the ancient one that it found on the system, and fail at runtime.
Here is the situation I had.
3 projects in solution.
Projects A and B have referenced Newtonsoft.Json.DLL 6.0.3 and a Solution Reference to project C. Project C has no any explicit reference to Newtonsoft.Json.DLL.
When building the solution it builds C, then A and B - dropping correct dll's in bin.
But when i build only C VS drops older version of dll to A and B. As no explicit reference or binding Redirect exists, it is taking it from GAC.
Also Building only A drops older dll into B, because it builds C at first drops wrong version into A and B, then builds A putting the correct version.
Here is the solution - explicitly add Newtonsoft.Json.DLL 6.0.3 to the project C
We recently ran into the same issue. Our solution would compile and have the correct DLLs on our development machines, but on our build agent the wrong version of Newtonsoft.Json would be dropped in the output folders.
After a lot of time invested, we discovered that this was triggered by someone installing a newer version of the Azure SDK on our build agent than we had locally: 2.9 instead of 2.5.1.
The workaround we discovered was to include the Newtonsoft.Json NuGet package in every project in the solution, even if the project had no need for the reference.
I have exact the same problem and was finding out that in C:\Program Files\Microsoft SDKs\Windows Azure.NET SDK\v2.3\ref I have Newtonsoft.Json.dll with the exact same date and time as the one that whas copied into my website folder.
After rename/delete the Newtonsoft.Json.dll in C:\Program Files\Microsoft SDKs\Windows Azure.NET SDK\v2.3\ref, Visual Studio was stopping to replacing my referenced version and the website start working again.
My scenario was almost exactly same except that my Newtonsoft.JSON DLL was copied from different location. I verified that my solution was referencing the correct file and version but on RUN VS copied it from another location (Check this first by dragging BIN DLL into VS or properties.
In end after trying them one by one using Fusion logs I went all out replacing all references of Newtonsoft.JSON.dll that has the same incorrect version from Program files:
'C:\Program Files (x86)\Microsoft SDKs\Microsoft Azure\Mobile
Services\1.0'
'C:\Program Files\Common Files\Microsoft Shared\Visual
Studio\12.0'
'C:\Program Files (x86)\Microsoft Visual Studio
12.0\Blend'
etc.
Quick tip: In explorer under details view add 'Product Version' as column and sort by it:
It still feels like crappy IDE behavior through if I set Specific Version for that Assembly and the file path is to the correct DLL (set by NuGet) it should really not go and override it with one from another share global location. Any comments to change Visual Studio build behavior here will be appreciated as I really don't want to do this type of manual hacks on each developers machine.
I ran into this same sort of problem today. I discovered that after a build of a class library, all the *.dll files in that class library’s output directory are copied into the bin folder of any web project that has a project reference to that class library. This can lead to compatible assemblies getting replaced with incompatible assemblies. However, this dll xcopy won’t happen while the web project is unloaded (right-click the project and choose “Unload Project”).
I have the same problem, after test all solutions I continue to get errors. Appear to be that this error can happen for multiple causes.
In my case I use VS 2015, the problem was a unused reference to other project in my application that use a older version of newtonSoft. I eliminate the reference and the dll was no more changed.
I came with same problem .
I had installed newtonsoft 11.0 version with nuget.
After building or publishing the solution the newtonsoft reference in bin folder was getting overwritten to 6.0 version and the published pages dll had the same 6.0 version.
Everything was fine (package.config,debug,release refernces).
After lot of tracing found the solution that worked for me.
So tried with following .
Renamed the newtonsoft.dll file in the Diagnostic folder at following location
Program Files\Microsoft SDKs\Azure.NET SDK\v2.8\bin\plugins\Diagnostics
It started working as expected.