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.
Related
I have C# application (.NET Framework 4.6.2) with WebApi projects which references System.Runtime.InteropServices.RuntimeInformation (v4.3.0) library through nuget package. See
Nuget package reference screen Package was auto-installed as a dependency of 'Microsoft.CodeAnalysis.Razor.2.2.0, Microsoft.DotNet.PlatformAbstractions.2.1.0'
This application was working fine (Builds from my localhost are ok) until I tried to do automatic builds from my teamcity server (different machine). For some reason builds of my app which are provided by teamcity will not start. I get error Could not load file or assembly 'System.Runtime.InteropServices.RuntimeInformation, Version=4.0.2.0...'
So I started to investigate and I found out this:
Builds from my localhost (bin/debug) contains lib System.Runtime.InteropServices.RuntimeInformation.dll (File version=4.6.26011.1, Date modified=10.8.2021) --this build works fine
Teamcity build contains lib System.Runtime.InteropServices.RuntimeInformation.dll (File version=4.6.24705.1, Date modified=11.5.2016) --this build is not working
Nuget package which was downloaded (..\packages\System.Runtime.InteropServices.RuntimeInformation.4.3.0) on both machines (localhost and teamcity server) contains System.Runtime.InteropServices.RuntimeInformation.dll (File version=4.6.24705.1, Date modified=11.5.2016)
And now I am stuck and literally dont know how to investigate it further. Questions I am asking myself:
How is it possible that my localhost builds contains this reference lib with file version 4.6.26011.1 when in my \packages\ folder this .dll contains file version 4.6.24705.1? Does msbuild maybe take this reference from different location? But from where? I swear I searched my computer and I did not found this library in version 4.6.26011.1 (which is apparently copied to bin/debug by msbuild).
Is there a way to monitor msbuild process and see from where it copies this .dll reference to my bin/debug/ folder on my localhost machine?
How to fix my references so the app runs fine?
21.6.2022 Edit:
Thanks to #mu88 comment I have managed to find out that this library is copied from this location: "C:\Program Files\JetBrains\JetBrains Rider 2021.2.2\tools\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net462\lib\System.Runtime.InteropServices.RuntimeInformation.dll" to my bin\debug. I have zero ideas why msbuild is using this path for this lib. (This is only library which is copied from this path)
--Additional info: I am using some AspNetCore references (e.g Kestrel, ..) so I am targeting .Net Standard 2.0. Could this relate? I am asking because my investigation lead to this issue: ms-build-extensions-file-corrupt-my-bin-web-api-folder. In this issue I have found other links to people having similiar problems like this. I just dont understand the solution there :(
So I managed to solve my problem. I had to install .NET SDK to Visual Studio Build Tools 2019 via Visual Studio Installer. Which done "some" magic and it created *MSBuild\Microsoft\Microsoft.NET.Build.Extensions* folder to my msbuild and now during the build process some System libraries are "overidden" and copied from this new location.
So even if I use nuget to download System lib then this package is not used during the build.
I did not manage to find any more info about the build process :( It would be nice if someone could explain this to me. I created a separate question for this here: What is Microsoft.NET.Build.Extensions and how does it work?.
I am working on a vsix project where I need to get information about a local git directory. I am following this article. When I am using LibGit2Sharp library, I am getting an exception as described in following image and error:-
How can I resolve this?
VS version details:
Visual Studio 2019
.Net Framework 4.7.2
LibGit2Sharp is a managed language (.NET) wrapper around a native (C) library, libgit2. It's a P/Invoke layer, plus a layer to give .NET semantics (objects, etc). This means, though, that you require both the LibGit2Sharp.dll (the managed-language side) and the git2-xxxxxxx.dll (the corresponding native library) that it calls into.
The native DLL is part of the LibGit2Sharp.NativeBinaries project that LibGit2Sharp takes a dependency on. It should be installed (transitively) when you install LibGit2Sharp itself. And although it tries to set itself up as a dependency that will be installed in the output directory, since native binaries are not well-understood in the .NET project world, this can sometimes fail, especially for more complex project types like VSIX.
Ultimately, LibGit2Sharp will look for the corresponding native DLL alongside where it's located. So within your output directory, wherever your VSIX is being executed from, try copying the git2-xxxxxxx.dll that is part of the LibGit2Sharp.NativeBinaries project to that location.
Once you've identified the correct location for the git2-xxxxxxx.dll binary to live, you should copy this as part of your installation for the project. (eg Build action: None, Copy to output directory: Copy always)
I had the same issue and I solved it like this:
Copy the dir folder from VisualStudioExtension -> Bin -> Debug -> lib to the root of the VisualStudioExtension project. This folder contains the DLL files required for LibGit2Sharp to work.
Drag the lib folder onto the VisualStudioExtension project in Visual Studio.
Select the dll files, right-click, Properties, and set it to Copy always and include in VSIX.
That worked for me.
LibGit2Sharp has a dependency on the git2-106a5f2.dll which is under [Debug|Release]\lib\win32\[x86|[x64] directory.
If that particular version is missing, you may need to reinstall LibGit2Sharp library, but uninstall LibGit2Sharp.NativeBinaries library between uninstall and install.
The following operations on NuGet packages should help:
Uninstall LibGit2Sharp.
Uninstall LibGit2Sharp.NativeBinaries.
Install LibGit2Sharp.
Note: do not update LibGit2Sharp.NativeBinaries even if there is a newer version.
I got the same issue. It turn out I ignored the dependecies.
Installing its dependency : LibGit2Sharp.NativeBinaries sort out my problem.
For me, I manually installed the Debug and Release VSIX, and tested against regular VS instance and it worked fine. The LibGit2Sharp threw a DllNotFoundException only when debugging my code via the Exp version of Visual Studio 2019.
So I deleted the entire Extensions folder of the Exp verison of Visual Studio. It is the folder where the Exp version of VS installs all Plugins, like other versions of VS:
%AppData%\Local\Microsoft\VisualStudio\16.0_a31c0a3aExp\Extensions
The next time I debugged my VSIX through Visual Studio, it worked. Hope this helps, I think it has something to do with extensions.en-US files inside that folder. Deleting just my plugin folder insted the Extensions folder did nothing.
We have written a service to be deployed to Azure. This consists of a DLL with a "Worker Role" class, and an Azure Cloud Service project, as shown below:
The build steps are:
Build the ccproj in "Release" configuration.
Run NuGet "spec", then "pack" to get a .nupkg file
Deploy the .nupkg file to the Azure Cloud Service
This has been working fine for a while, until we upgraded to .NET 4.6.2 and also upgraded several other references, including System.Runtime (now v4.3.1). Now, despite the fact that we have (probably unnecessarily) added a NuGet reference to every single project in the solution, pointing to System.Runtime 4.3.1, the version of System.Runtime.dll that gets deployed is an older version, resulting in DLL hell on the service, which then fails to run. If we manually copy over the correct version of System.Runtime.dll, then everything works again.
Where is this incorrect version of System.Runtime coming from? And how do we convince the offending software/hardware to use the correct version?
UPDATE: Trail is getting warmer. On my development machine, the bin folder of the EventWorker project contains the correct version of System.Runtime.dll. But... the EventProcessor\obj\debug\EventWorker folder contains the old version! I deleted the obj folder and recompiled the project - and the old version of the DLL appears again.
Where is it coming from, and how to fix?
You have the right idea in terms of hunting down the offending DLL. Have you any dependent DLL's which could be using the wrong version? Also, when run locally does it give you the dll conflict warning in the errors window, allowing you to identify where? Take a look at your config file and see if you have a reference to the DLL version in the redirects section, update it or create a new one to point at the latest version.
Well, I fixed it, but I'm not sure why this worked. I removed the NuGet reference to System.Runtime from the EventWorker project. And now the EventProcessorRole is using the correct version of the DLL.
I'll mark this as the answer in the meantime, but if anyone can provide an explanation for this behavior, I'll give you answer credit...
I am trying to generate help files using Sandcastle, locally this works find but on my build server I keep receiving the same error message:
SHFB: Error BE0073: A project with a different or higher framework version was
found but that version (.NETFramework 4.5) or a suitable redirected version
was not found
I have checked and I have .NET 4.5.1 installed and 4.5, my projects build without an issue on the server. It is only Sandcastle that is causing a problem.
Does anyone know the cause of this error or how I can diagnose it further?
For some reason the directory:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5
Was missing on my build server. I copied it from my local machine and everything started to work.
I was experiencing the same issue trying to configure VSTS.
SHFB: Error BE0071: Unable to locate information for the project framework version '.NET Framework 4.6.1' or a suitable redirected version on this system. See error number help topic for details.
The LastBuild.log showed that it was not finding the .NETFramework folder.
Finding tools...
The Sandcastle tools are located in 'd:\a\1\s\packages\EWSoftware.SHFB.2017.1.28.0\Tools\'
The SHFBROOT system environment variable was not found. This variable is usually created during installation and may require a reboot. It has been defined temporarily for this process as: SHFBROOT=d:\a\1\s\packages\EWSoftware.SHFB.2017.1.28.0\Tools\
Locating components in the following folder(s):
d:\a\1\s\Documentation\Project.Docs
C:\ProgramData\EWSoftware\Sandcastle Help File Builder\Components and Plug-Ins\
d:\a\1\s\packages\EWSoftware.SHFB.2017.1.28.0\Tools\
Last step completed in 00:00:00.0360
I ended up setting the Project-specific components path in the project properties to point to the SHFB .NET Framework package and this solved the problem.
For me this message occurred after I had installed the Sandcastle Help File Builder application on our build server, but the build logs were complaining that the SHFBROOT environment variable wasn't found, but I had configured an override in the Help File Builder project which the build log said it would use instead.
<PropertyGroup>
<!-- NOTE: Update the version number in the path (YYYY.M.D.R) to match the package version -->
<SHFBROOT Condition=" '$(SHFBROOT)' == '' ">$(MSBuildThisFileDirectory)\..\packages\EWSoftware.SHFB.2017.1.28.0\tools\</SHFBROOT>
</PropertyGroup>
The above setting didn't help me on the build server however and it was still failing (but not locally).
What did work for my case was a reboot of our build server.
A fairly obvious oversight on my part, as I expect this is somewhere in the help documentation that I may have initially missed.
I had this related issue with running it on the build server:
BE0071: Unable to locate information for the project framework version 'XXXX'
Cause
The build engine was unable to locate framework information for the version specified in the project's FrameworkVersion property. An attempt was made to redirect usage to a later version but none were found.
Solution
This can happen if you select a framework that is not installed on the system. For example, choosing an earlier version of the Silverlight framework. If the earlier version is not found, the build engine will attempt to redirect usage to a later version of the framework if one can be found on the system. If the specified version or a later version cannot be found, you will need to install the selected or later version of the framework specified in the project on the system.
The framework assemblies are searched for in the Reference Assemblies folder (%ProgramFiles(x86)%\Reference Assemblies\Microsoft\Framework). If you have not installed a version of Visual Studio related to the indicated framework version or the related targeting pack, the reference assemblies may not exist there. The simplest solution is to download and install the appropriate targeting pack or copy the reference assemblies from another system that does have them.
If using the Sandcastle Help File Builder NuGet package, it may mean that you need to install one or more of the help file builder Reflection Data Set packages which contain the necessary files. If multiple versions of the platform package exist, install the latest release as it will cover all prior releases as well. Be sure to set the project's Component Path project property to the packages folder if it is not under the help file build project folder. Once installed and the component path is set, you may need to close and reopen the project in order for it to detect the newly installed files.
I'm trying to deploy a Clickonce application that refercences the Roselyn assemblies through Nuget packages.
The Roslyn Nuget packages have version 1.2.20906.2 but:
When I look at the dll properties in the packages folder I see
the DLLs have version 1.2.20906.1
When I look at the references properties in the VS2012 Solution Explorer, it shows version 1.2.0.0 (the path points to the Nuget package dll)
Local copy is set to true as is Specific version for all Roslyn references.
When I publish my clickonce, the Dll included and deployed have version 1.2.20906.1 but the Clickonce manifest states:
<dependency>
<dependentAssembly dependencyType="install" allowDelayedBinding="true" codebase="Roslyn.Services.dll" size="1345672">
<assemblyIdentity name="Roslyn.Services" version="1.2.0.0" publicKeyToken="31BF3856AD364E35" language="neutral" processorArchitecture="msil" />
...
So version in the manifest is 1.2.0.0.
When I try to install the Clickonce on the client, I get an error message (translated from french): Reference in the manifest does not match the identity of the downloaded assembly Roslyn.Services.dll
The client machine is Windows 7 x86.
I tried to target AnyCPU and x86 in my VS project without success.
When I deploy via xcopy on the target machine, the app runs fine.
Any help appreciated.
Where does the reference in VS point to? Does it point to the packages folder? If not, it should, since that's the assembly you want to deploy. You should delete the reference and re-add it, pointing to the one with the version you want to deploy. It might be accessing the old version in the GAC and then publishing the new version, which won't work. ClickOnce is very specific, and the versions must match.