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.
Related
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.
I am building a Cpp/Clr dll with .NET Framework 2.0. Builds fine. However, when I create an Example program to use the dll, also with 2.0, I get this error:
The primary reference "C:\...\MemBuffDll.dll" could not be resolved because it has an indirect dependency on the .NET Framework assembly "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "4.0.0.0" than the version "2.0.0.0" in the current target framework.
I have very carefully rebuild the entire solution (not too hard, only two projects in it) and made sure I used only cut and paste of code from one file to another in the re-creation. I as VERY careful to make sure I specified the 2.0 Framework.
When I exclude the Example Solution, everything builds fine. When I reload it, I get the above message. So, I searched in the contents of every file in the entire solution and found the reference in both the .dll and in a file ending with .metagen. The metagen lines of interest are:
ImageRuntimeVersion: v4.0.30319
Assembly MemBuffDll, Version=0.0.*, Culture=Invariant Language (Invariant Country):
hash=SHA1, flags=PublicKey
Assembly mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089:
hash=None, flags=None
Assembly mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089:
hash=None, flags=None
Assembly System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089:
hash=None, flags=None
Why are the two lines with 4.0.0.0 in there? This is supposed to be a 2.0 build.
Really puzzled,
-greenhorn greg
The answer to the question is:
"The C++ IDE does not support multi-targeting"
Because I didn't understand this answer when I'd seen it in other posts, I'm going to try and clarify for the benefit of other poor souls who stumble upon this "feature".
What this means is that my VS 2010 cannot (correctly) target .net 2.0 when I'm doing a C++ project. I had specified .net framework 2.0 for both of my projects in my solution and the settings were accepted. However, the C++ portion (actually C++/CLI) actually built with two references, both the v2.0 that I had specified and v4.0 that is the native(?) for my VS 2010. Note that it did not throw an error or warning and only the .dll and the .metagen files contained this reference.
When the other project in my solution tried to reference the project, I got the error mentioned in my OP. It would not build.
The solution to the problem is twofold:
Install VS 2008 and recreate the problem project under that. Will probably need refactoring. Note that the Express edition worked just fine for this.
Change your targets to .net 4.0. This is what I did because refactoring the dll would be a PITA and the target platform (Windows Embedded 8 Standard) supports .net 4.0
Hope this helps somebody else like me that runs into this.
I am having some issues trying to get my automated builds to compile projects that reference Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll. For some reason the project fails to compile complaining that
Could not resolve this reference. Could not locate the assembly "Microsoft.VisualStudio.QualityTools.UnitTestFramework, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL". Check to make sure the assembly exists on disk.
I have installed VS2010 Premium on my build server but this does not seem to have resolved the issue. Am I missing something here?
Your version Version=9.0.0.0 is part of VS2008, so it makes sense that it can't be found on your build server even though you 've installed VS2010.Consider changing your project-ref into Version=10.0.0.0 which corresponds to your current VS-version.
I have a project using DevExpress 8.3 (2008.3) which I just recently upgraded to use VS 2010. After doing so, everything compiled fine but I got errors trying to use the designer. I resolved this as described here:
NetFx40_LegacySecurityPolicy in design-time mode
by adding <NetFx40_LegacySecurityPolicy enabled="true"/> to my devenv.exe.config.
Designer works fine now, but some of the projects in the solution which have COM references no longer compile, with the exception:
The "ResolveComReference" task could not be instantiated from "Microsoft.Build.Tasks.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". The security state of an AppDomain was modified by an AppDomainManager configured with the NoSecurityChanges flag.
The COM references for those projects are also flagged with a yellow exclamation mark.
The only google result I found for this error was here:
http://social.msdn.microsoft.com/Forums/en/vsx/thread/197b8dca-5610-4ac5-86fc-c56d5182e46b
which describes the exact same problem but with no resolution. I tried adding
<GenerateResourceNeverLockTypeAssemblies>true<GenerateResourceNeverLockTypeAssemblies>
as the post suggests but that doesn't have any effect for me.
Anyone know anything about this?
Thanks.
I logged into my DX account and found (to my surprise) that DX was offering me an upgrade to a new hotfix version of the same 2008.3 release (even though my subscription is expired). This fixed the problem (and allowed me not to have to use Legacy Security Policy at all).
I want to learn to use Fluent NHibernate, and I'm working in VS2010 Beta2, compiling against .NET 4, but I'm experiencing some problems.
Summary
My main problem (at the moment) is that the namespace FluentNHibernate isn't available even though I've imported all the .dll assemblies mentioned in this guide.
This is what I've done:
1. I downloaded the Fluent NHibernate source from here, extracted the .zip and opened the solution in VS. A dialog asked me if I wanted to convert the solution to a VS2010 solution, so I did.
2. I then went into each project's properties and configured all of them to compile for .NET 4, and built the entire solution.
3. I copied all the .dll files from /bin/Debug/ in the FluentNHibernate to a new folder on my local hard drive.
4. In my example project, I referenced FluentNHibernate.dll and NHibernate.dll from the new folder.
This is my problem:
If I right-click on FluentNHibernate in the References list and select "View in Object Browser...", it shows up correctly.
Now, when I try to create a mapping class, I can't import FluentNHibernate. This code:
using FluentNHibernate.Mapping;
namespace FluentNHExample.Mappings
{
}
generates an error on the using statement, saying
The type or namespace 'FluentNHibernate' could not be found (are you missing a using directive or an assembly reference?).
The FluentNHibernate assembly is still in the list of References of my project, but if I try to browse the assembly in Object Browser again, it can't be found.
What is causing this?
I also had similar problem.
"Error List" window displayed:
The type or namespace name 'FluentNHibernate' could not be found (are you missing a using directive or an assembly reference?)
But "Output" window was displaying detailed information:
warning MSB3253: The referenced assembly "FluentNHibernate" could not be resolved because it has a dependency on "System.Data.OracleClient, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which is not in the currently targeted framework ".NETFramework,Version=v4.0,Profile=Client". Please remove references to assemblies not in the targeted framework or consider retargeting your project.
In my case; I had created a console application project which was targeting ".Net Framework 4 Client Profile" by default, so changing to ".Net Framework 4" fixed issue for me.
I'm unable to observe this behavior in my build, could it be related to this problem: Weird override problem with Fluent NHibernate and .NET 4
If so you could try http://groups.google.com/group/fluent-nhibernate/browse_thread/thread/ae4013d711d2e4ad as a potential fix.
Isn't there a better way to fix this problem?
I don't want to reference System.Data.OracleClient. So I shouldn't have to target the full .Net framework if I don't even want that reference.
Can't I target the Client Profile of the .Net framework, but add a compiler warning exception somewhere so that it just skips that warning? I know it won't cause a runtime problem because I don't use Oracle.
I get identical problem which says there's also a dependency on System.Web. Same story, this is for a Windows WPF app, so I don't need System.Web. Can't I just target the Client Profile and somehow convince the compiler to keep going?
Thanks,
Hugh
EDIT: I figured this out! I had to compile NHibernate myself though. Opened the 2.1.2 code in Visual Studio and deleted everything that says "Oracle" or "System.Web" and I ended up getting it to build. I do not have to target the full .Net Framework now.
We had this issue and the issue went away if we removed the obj and bin folder from the project which was referencing the NHibernate using project.
So we have 'project1' which uses NHibernate to produce project1.dll.
'project2' references project1.dll.
Problem resolved if we removed the obj/bin folder from project2.
Can't say why, but our solution now compiles fine.
Mike.