On a new Win8.1 reinstall, with all of my code restored from backup, I'm suddenly now getting a Visual Studio warning when I build the main project of my solution:
Found conflicts between different versions of the same dependent assembly that could not be resolved. These reference conflicts are listed in the build log when log verbosity is set to detailed.
I set the Output log level to Detailed and I found a few entries like this:
There was a conflict between "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" and "mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes". "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" was chosen because it had a higher version.
Trouble is, I'm not referencing mscorlib anywhere in the solution—old or new. I have a couple of apps on my machine that require .NET 3.5, but I can't see how that could be related.
One difference: the old Win8.1 install on which this warning did NOT occur was a standalone machine; this time I'm domain-joined. I don't know whether that makes a difference (I can't see how), but I thought I ought to mention it at least.
Having different versions of a Nuget package on different projects may cause this problem as well. Make sure that all your packages have the same version:
(Within Visual Studio) Right click on the solution
Click on Manage Nuget packages for Solution
Click on the Consolidate tab
For every package in the Consolidate tab, update the package to the same version for every project.
I was able to fix this by issuing an update-package -reinstall command at the Package Manager Console.
BUT
Be careful, updating all the packages in your solution could cause other problems, make sure you can roll back to a good version if it goes wrong!
I have been able to fix this issue by deleting my ".suo" file of my solution and then re-opening the solution. I then rebuild the solution and the issue is gone.
The ".suo" file is within the ".vs" folder which is what I usually delete.
Good luck!
I solved this by setting my verbosity to Diagnostic as per this answer.
Once I did that and rebuilt my solution, the build log actually listed the specific packages that depend on the two different versions of mscorlib.
In my particular case, my project had references to version 2.0.20126.16343 of System.Net.Http. I opened up the NuGet Package Manager and updated this package to the latest version (4.3.4 at the time). The next time I built my solution, the warnings were gone.
Well my solution is a little bit simpler than all of the above. I simply added a reference to the two Assemblies throwing this error (System.Runtime.Serialization and mscorlib) and rebuilt the project. By doing this, I specified the 4.0.0.0 version and removed the ambiguity.
One of the two (mscorlib) couldn't be added via the GUI because of the "A reference to 'mscorlib' could not be added. This component is already automatically referenced by the build system." error.
I needed to open the .vbproj (.csproj) file and add a reference manually via:
<Reference Include="mscorlib" />
I've tried all the following, but none has resolved the issue.
the command "update-package -reinstall".
Update and package via Consolidate tab.
Removing the ".suo" file.
However, My issue was a different case, I guess the new version of Xamarin.Forms package has used a different version of mscorlib. so I've downgraded it and it works fine.
I suggest you try all above solutions and also try to find which package is conflicting.
Following Memet Olsen's advice using VS2017 community...almost identical:
Right click Solution in Solution Explorer.
Select 'Manage Nuget Packages for Solution'
Check the packages. If any of them have a blue up-arrow rather than a green tick use the 'update' button
I also have tried all of the proposed solution to no avail.
In my project, this warning message was caused by a dll reference having a dependency on a different .net framework than the one that is targeted by my project.
In order to find out which dll reference was causing the warning, I simply used .net reflector to explore each dll reference to find out which one was referring a different .net framework (mscorlib).
In order to fix the issue, the reference dll has to be updated to a version which targets the same .net framework as the project using it, if such a version exist.
Hope this helps.
Related
In my solution some projects reference the "MahApps" NuGet package, which includes 'System.Windows.Interactivity.dll' 4.5.0.0. Some projects also reference the "Prism" NuGet package, which includes 'System.Windows.Interactivity.dll' 4.0.0.0.
The app.config has a binding redirect of "0.0.0.0-4.5.0.0" to "4.5.0.0" by the way.
A handful of projects reference both NuGet packages, and looking in their "References" lists some of them have S.W.I v4.5.0.0 while others have v4.0.0.0. (I'm guessing this randomness is down to the order in which the packages were installed to the projects).
Sometimes the solution will build and run fine, but if only make a code change in one of the projects referencing S.W.I 4.0.0.0 then I get a runtime error along the lines of "v4.5.0.0 could not be found". v4.0.0.0 is being copied to the build output folder but my binding redirect is telling it to expect 4.5.0.0.
Any thoughts on a solution? I could try uninstalling and reinstalling the packages in the projects causing the issue, to see if I can get them to reference the 4.5.0.0 in the MahApps package, but my concern is that this may not be guaranteed to work during a package restore, screwing it up for another developer (or the build server).
I ended up upgrading to Prism 6, which includes no DLLs other than its own. Thankfully it was a straightforward job.
I also had to remove the MahApps package then add it again, to get Visual Studio to add that package's System.Windows.Interactivity.dll (4.5.0.0).
This morning I upgraded to VS 2017 15.3 and now am getting yellow triangles for most of my references. The project runs fine (build is good in CLI and VS and restore has been run multiple times) that I can tell (and even better on dotnetcore 2.0 actually) but these remain. Has anyone else had this happen or have a suggestion? Thanks.
Link to project.assets.json file --> https://www.dropbox.com/s/c85yuyjiu4pnget/project.assets?dl=0
Also issue of greyed out usings and red references although everything builds and runs fine.
Update: VisualStudio twitter account responded to me to note that this is a bug and they are working on a fix for the future on this....
I have two responses to my post:
1) The using issue noted with things greyed out was actually a ReSharper issue. If you upgrade to VS 2017 15.3 and use R# make sure you update it as well to 2017.2.
2) The Yellow triangles issue is being looked at by the Visual Studio team but honestly I believe it to be linked to warnings in the build that those references are being coerced to either lower dependencies (ie Newtonsoft at different levels) or previews. The quickly evolving .NET 2.0 world may have exacerbated this issue. Yellow triangles have traditionally meant missing but check your warnings to see if that is related and then review the dependency chain. I will update this answer once I hear back from VS team (shout out to them and Damian Edwards + Scott Hanselman for helping me with this on Twitter).
I was experiencing the yellow triangle on references issue after updating the projects in my (.NET 4.6.1) solution to the new .NET Standard .csproj format that comes with VS2017. The references I was getting warnings for were ProjectReference type (although it seemed to spill over into PackageReference for common packages in the projects in question).
I did not have any build warnings and there was nothing in the verbose build output to indicate what the cause could be.
I could follow all warnings back to a single project in my solution. I was able to solve by removing that project from my solution and then adding it back and re-adding only the necessary project references.
It seems the issue was related to unnecessary project references (or possibly circular) caused by the new transitive dependencies support. After removing the project and adding it back with only the minimum ProjectReferences and relying on transitive dependencies support to propagate the dependency, the warnings all disappeared.
This also solved an issue where the project in question was failing compilation during a command line msbuild initiated build on my CI server which only has VS2017 build tools installed (not the full IDE).
I had the same issue, some of the references were marked with the yellow triangle. However, I was able to build and run my project.
I managed to remove these warning by following steps from this answer:
.Net 2015 References with yellow triangle for Nuget packages on portable libraries
I turned on tracing for Visual Studio, I had next warnings in log files for all uncorrectly loaded references:
Encountered conflict between 'Reference:Microsoft.Win32.Primitives, Version=4.0.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL' and 'Reference:C:\Program Files (x86)\Visual Studio\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\ref\Microsoft.Win32.Primitives.dll'. Choosing 'Reference:C:\Program Files (x86)\Visual Studio\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net461\ref\Microsoft.Win32.Primitives.dll' because AssemblyVersion '4.0.3.0' is greater than '4.0.2.0'.
To be precise, I did next steps:
Removed error condition from my .csproj file
Removed <Private>true</Private> parameter for not-loaded references in .csproj file
Deleted not-loaded packages from \lib and \ref folders in corresponding MSBuild folder.
Deleted packages from \packages folder in solution.
Restored nuget packages.
I'm not sure all these steps are necessary, but it worked for me.
You could check my answer on relative topic here: https://stackoverflow.com/a/59704420/7969733
Just for documentation purpose for new person with this issue try
this and you will rememberme :D
If you go to: Tools > NuGet Administrator > Configurations. and you
have "Allow nuget...." and "automatically check...." cheked.
The only thing than you have to do is click con the button "Clear
All NuGet Cache(s)"
That's it, you don't have to edit manual thinks than can be dangerous,
believe me, I use to need to done some of the steps than describe here
a lot of time, and try more than 5 steps of the official Microsoft
documentation for that issue you could check it here:
https://learn.microsoft.com/nuget/consume-packages/package-restore#restore-packages-automatically-using-visual-studio
But just cleaning the cache solve all the problems
To "Clear All NuGet Cache(s)" in Visual Studio 2019
Tools->NuGet Package Manager->Package Manager Setting
Mismatched Windows SDK Version between the referencing project and the references will cause it. In the vcxproj file it is "<WindowsTargetPlatformVersion>SDK Version</WindowsTargetPlatformVersion>"
I was upgrading from VS2012 to VS2017. Everything was good, then I upgraded to a new version of libtomcrypt and libtommath. Rather than tweak my existing projects, I up-converted the projects from the distributions from VS2008 -> VS2012 -> VS2017. In the process, I picked up Windows SDK Version 10.0.17763.0 in both the new projects. However, all of the projects that referenced those were 8.1, and thus the warning.
I know that this was ready to solve it, and one of my answers was ready to say something about that, but, maybe some of you present the same error and none of this solution listed here solves the problem... I don't know why this problem comes with the global installation of .net 6, but, if you present this issue again, you need to go to
C:\Users\YourUsername.nuget
And delete all the content, don't be afraid, that's a cache generator than will be created again if is need it.
I had a similar issue with visual studio 2017. And discovered that, if when I changed the dependency settings of the package I wanted to install (from lowest dependency to highest) everything worked fine.
Today faced the same issue with an imported project.
FAILED ATTEMPTS: Tried updating nougat packages, checking improper imports and everything imaginable. No help.
SOLUTION: At last just tried building the solution and it worked!
PS: Try building the project first. If it does not work then go for solution hunting.
I somehow brought my project to a state where Visual Studio 2013 fails to compile it with a ridiculous error:
The type 'System.Collections.Generic.Dictionary`2' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Collections, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
First of all, there is no such assembly, it does not exist.
Second, Dictionary<TKey, TValue> is defined in mscorlib.dll, which is referenced by default, of course. Resharper (which has its own code analysis engine) reports that the solution should compile normally.
I don't know how on Earth it could happen, because my latest changes have nothing to do with the supposedly erroneous place at all. The line references some standard LINQ functions (GroupBy and ToDictionary), and it worked for months without any changes. Unfortunately, I cannot create any MREs: obviously, this error only appears in the context of my huge solution, and only with some specific changes made in the presumably irrelevant places.
Here's what I tried, and it didn't work:
Clean + Rebuild
Changing target Framework from .NET 4.5 to .NET 4.5.1 or .NET 4.0
Has anyone seen such a quirk before?
I had the same problem, but it was on a website project - not any easy way to remove & re-add the references. Luckily, I found that this answer worked for me - and was even quicker than messing with references
https://stackoverflow.com/a/29575865/3841490
adding a new assembly tag to web.config seems to have resolved this
issue. The tag I added was under the tag and as follows:
<assemblies>
<add assembly="System.Collections, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</assemblies>
I had the exact same issue and it seemed to be related to two NuGet packages containing the same assembly "System.Collections.Immutable". The two NuGet packages where "Microsoft.Bcl.Immutable" (Unlisted) and "System.Collections.Immutable".
I haven't been able to reproduce the issue reliably, and it seems the problem was solved by using VS2015.
However, i would suggest looking for NuGet packages containing the same assembly.
Removing Microsoft.Bcl.Immutables solved this for me.
Check that all the (core .net) references in your project are valid and they all reference the same .NET framework version.
If in doubt, remove all references and add them again (using the 4.0.0.0) versions.
I had this happen to me once (with the exact same error) and it was due to some "screw up" on the version of the references. I never got to find out WHY it happened, but removing all references and adding them again worked for me.
I'm working on a project that uses nuget but does not use package restore. (This is a decision outside of my control by the way, so any answers that involve enabling package restore aren't ones I'll be able to use.)
A handful of projects in the solution (4 out of a total of 34; a WinJS app store project, two ordinary .NET class library, and one of my Azure cloud projects) are reporting this infamous warning:
...packages\Microsoft.Bcl.Build.1.0.13\tools\Microsoft.Bcl.Build.targets(225,5): warning : All projects referencing Valhalla.Consumer.Core.csproj must install nuget package Microsoft.Bcl.Build. For more information, see http://go.microsoft.com/fwlink/?LinkID=317569.
That link assumes that I'll want to turn package restore on. So does every other bit of advice I've managed to find so far on this subject.
I tried disabling Package Restore in Options -> Package Manager -> General settings, by the way. That doesn't help (and even if it did, it would be undesirable - I use package restore in everything else I work on).
I don't really understand why I'm getting this in a solution that doesn't use package restore. As I understand it, the whole point of the package it's asking for is to support package restore. So in a solution in which package restore is not in use, it seems odd for this package to be present.
However, it appears that certain other nuget packages cause you to depend on this. I have a Windows Runtime Component project that uses Microsoft.Bcl, a nuget package that, for some reason, has a dependency on Microsoft.Bcl.Build. (Visual Studio seemed to add the Microsoft.Bcl package for me when I created the project. Presumably it's necessary.) Other projects seem to acquire a dependency on Microsoft.Bcl.Build via the HTTP client libraries.
So apparently, certain common nuget packages appear to force a dependency on Microsoft.Bcl.Build whether or not you're using package restore.
That would be fine if you could eliminate the warning simply by adding the relevant package to all projects that get this warning. But the vexing thing is that even if I add the Microsoft.Bcl.Build package to the consuming components (e.g., my WinJS Window Store app) I still get this warning! (So it continues to complain that I need to install the nuget package even after I have installed it.)
Does anyone know how to eliminate this warning in this situation? Doing what it asks me to do doesn't seem to be sufficient. What's missing?
I had the same issue. Updating the Microsoft.Bcl.Build package from 1.0.13 to 1.0.14 solved my problem.
We recently had the same issue. Using Nuget 2.8, BCL build 1.0.14, BCL 1.1.9, we had a project A using BCL build, that was referenced by another project B.
Short story: Project B compilation gave the mentioned error although the packaged were added to it. The solution was to remove the packages and re-add them. We ended up doing that for both project A and B.
I believe the cause of the problem was a mismatch in versions. The original project referenced BCL 1.1.8 (the latest version when it was created) was while project B automatically used the more recent BCL 1.1.9.
I am not sure if that's relevant but on the first time we added packages using the project->NuGet package manager, and on the 2'nd time we used the NuGet Console (Tools->Nuget->console).
The remove,add caused a distinct difference in the csproj of project B.
the following lines were added:
<Import Project="..\..\..\packages\Microsoft.Bcl.Build.1.0.14\tools\Microsoft.Bcl.Build.targets" Condition="Exists('..\..\..\packages\Microsoft.Bcl.Build.1.0.14\tools\Microsoft.Bcl.Build.targets')" />
Issue: Just started today, all references to any assembly outside of the solution fail to resolve, with The referenced component 'SomeComponent' could not be found. when trying to build. This happens for both 3rd party components (all 15 or so of them) as well as all .NET Framework assemblies - basically anything that isn't another project in the same solution.
Trying to load some other solutions produced the same issue. Creating a new WinForms project worked without a problem, however. (Scratch that, it worked before reinstalling VS, now that doesn't work either. I created a new WinForms app as well as a WPF app, and the designer can't load the assemblies either. I tried targetting 3.5 and 2.0 and no luck.)
Things I've tried:
Repair Visual Studio installation
Rebooting computer
Started VS with /resetsettings flag
System Restore to 2 days ago when it was known to be working
Uninstalling VS and reinstalling
Fresh checkout from SVN
Does anyone have any experience with this and know of a way to get this working again? My strongest Google-fu has failed me, so I'm asking here. Can mark community wiki if requested.
Update:
I tried "upgrading" Windows (to the same version) since I didn't see a repair option for Vista and it's still a no-go. I reinstalled everything that seemed relevant. So far, it's looking like I'm just gonna have to back up and reformat I guess unless a solution comes up sometime before tomorrow.
Update2:
I just backed up data and reformatted, so I'm no longer able to verify any ideas that I haven't tried yet, so I'll just leave the bounty to expire on its own to the top voted answer and as a reference to anyone else who may have this problem later.
I had the same problem. It turns out that something was wrong with NuGet. I removed the following part of the *.csproj-File (opened in a text editor). This has solved the issue for me:
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('$(SolutionDir)\.nuget\NuGet.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(SolutionDir)\.nuget\NuGet.targets'))" />
</Target>
In my case, the solution was completely different. It looked like it was an issue with NuGet paths (caused by my moving the project to a different solution and then back again.
I edited the .csproj and removed all references to NuGet and associated packages. I also removed the packages folder from the solution folder.
The system components then magically reappeared.
Suggested next debug step: review Project Designer: References -> Reference Paths to verify that the paths to your system and third-party components appear correctly. (Watch out for things that can slip past the old Mark I Eyeball like drive letters.)
Try running VS after turing on Assembly load logging with fuslogvw. You'll be able to see additional errors captured by the runtime when it tries to locate and load the assemblies.
In Vista, you'll have to run fuslogvw as an administrator and somtimes specify an explicit path to save the logs.
You can also try debugging Visual Studio by attaching to it from another instance, or with the basic debugger included with the .NET SDK.
I had this similar issue not too long ago.
I found that the issue was caused by git not properly creating .exe's when jumping from branch to branch(we have nuget.exe in a path and it was getting deleted/added when jumping branches). When you would try to run nuget, windows would throw a fit over the exe.
After reseting the branch many times, I finaly got the exe to run properly. Then I noticed that the security on all the directories in the repo had been reset, so I had to deal with that.
After all of that, visual studio then started to play nice.
Hoped this helps someone!
It may also be a problem with references of other projects in the same solution. I only wanted to build one project, but got this message about references in another project. Although the problem in the other project was correct, I think the message was not correct:
I did not expect the message about another project (the other project was no dependency, so it did not 'need' to be built)
I could not 'interpret' it, because it did not mention the project it was about).
Well, if you click on the error, in VS 2012 RC, and then debug it, the error is gone...
I know that this is an old question but it is still happening in the latest version of Visual Studio (2015). I fixed it in a different way that might not have been available back when the question was asked. Basically, it is related to the fact that VS can't find the .Net Library package. To fix in the latest version of Visual Studio (2015):
Right Click on your solution in the Solution Manager. Choose "Manage NuGet Packages for Solution..."
in the NuGet Window, go to "Installed".
If you have something related to Microsoft.Net such as "Microsoft.NetCore.UniversalWindowsPlatform", remember the name and uninstall the package.
Now go to the browse tab and find the package and install it again. Don't forget to select the correct needed project.
Everything should be ok now.
I hope this helps somebody!
I hate to say it, but it sounds like the system is pretty borked. There has to be a point when it is quicker to reinstall the OS than it is to continue trying to fix the current install.
I just hope you take this in the right spirit... sorry.
Shot in the dark here, but I've run into the same (similar) problem. The issue I ran into was related to having a 64bit machine and running a project that had a mixture of 64bit and 32bit 3rd party dll's. The solution was to ensure I had the correct bits (32v64) and then to have the project build in 32 bit mode: project properties > build > platform target: x86.
Another time this occurred I had to remove all the 64bit dll's and reinstall with the 32bit dll's
HTH's
.nuget folder was missing. add the .nuget folder with nuget files (usually 3 files). open the solution and no warnings on references. My submodule has nuget references and when I pulled the latest version, the solution needs .nuget folder in the project folder.
i.e.
project
/.nuget
/submodule
/.nuget
Visual Studio was unable to find any of my references.
What i did, and following some solutions above, was:
Right click solution entry in Solution Manager window;
In the newly opened NuGet window go to installed, select all entries and update.
The problem gets solved!
Check your output with ILDASM to make sure the references are showing up correctly -- compare them to an assembly that works, and see if anything jumps out at you.
I once encountered a problem, which is in the *.csproj file. It defines an Error node in the Target node, that if one reference/nuget-library doesn't exist, it throws the error while building. The problem is VS do not show correct status for other libraries, thus all the referenced libraries looks like non-loaded, that the local file path cannot be found in the property window.
Here is a sample.
<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
<ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. xxx.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('..\packages\...\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\...\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props'))" />
<Error Condition="!Exists('..\packages\NOT-Exist.targets')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\NOT-Exist.targets'))" />
</Target>
...