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.
Related
In a Xamarin.Forms project I am getting an error on Windows 8.1 and UWP:
Could not load file or assembly 'FSharp.Core, Version=3.259.3.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
The actual version of F# used throughout the solution is 3.7.4.0:
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
<TargetFrameworkProfile>Profile7</TargetFrameworkProfile>
<TargetProfile>netcore</TargetProfile>
<TargetFSharpCoreVersion>3.7.4.0</TargetFSharpCoreVersion>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
There is an F# PCL project and C# platform-specific projects. The error occurs only when using F# libraries from Nuget in the PCL. These packages tend to use:
<TargetFSharpCoreVersion>3.259.3.1</TargetFSharpCoreVersion>
I have tried the following, but they do not change the error:
Putting an app.config file with a binding redirect to 3.7.4.0 in the F# project and/or the build directory
Installing the FSharp.Core Nuget package into all projects
Very grateful for any help.
Edit: in the original question there was an incompatibility between the profile (111) and the intended TargetFSharpCoreVersion (3.7.4.0) which was causing additional issues.
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 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 able to open a saved copy of my project in visual studio and it runs fine. After I rebuild the project it gives me the following error :
Could not load file or assembly 'System.Web.Ajax, Version=3.0.31106.0, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e' or one of its dependencies. The system cannot find the file specified.
this is driving me crazy. please help
Use Fuslogvw.exe to troubleshoot this problem. It shows you where the CLR looked for the assembly.
I have VS 2005, 2008 on my dev box.
New project from other developers who only have 2005 installed. When I build it I get error.
Error 1 Indirect reference is being made to assembly
System.Web.Extensions version 3.5.0.0, which contains
'AjaxControlToolkit.CalendarExtender'. This Project references a prior
version of System.Web.Extensions version 1.0.61025.0. To use
'AjaxControlToolkit.CalendarExtender', you must replace the reference
to System.Web.Extensions with version 3.5.0.0 or higher.
When I change the version of Web.Extentions to 3.5 I get another failure
Could not load file or assembly 'AjaxControlToolkit,
Version=1.0.20229.23876, Culture=neutral,
PublicKeyToken=28f01b0e84b6d53e' or one of its dependencies. The
located assembly's manifest definition does not match the assembly
reference. (Exception from HRESULT: 0x80131040)
Should I change the Public key for:
add assembly="System.Web.Extensions, Version=1.0.61025.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35"
to the newer one, or is this the wrong thing to do. the Server does NOT have 3.5 runtime.
TIA
If your server doesn't have the 3.5 runtime and you aren't able to install it, I suppose you must stick with the 1.0.61025.0 version of System.Web.Extensions.
I would guess that the problem you are encountering is because the AjaxControlToolkit dll that you are using was built with the 3.5 runtime. Thus, your project is referring both to the 1.0.6... version directly and to the 3.5 version through the AjaxControlToolkit reference, and getting confused. You might try downloading the toolkit source and building it from scratch, referencing the 1.0.61025.0 version of System.Web.Extensions. Then make sure to reference this toolkit instead of the default one.
http://ajaxcontroltoolkit.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=11121
Also, you might try making sure that all the references to the System.Web.Extensions DLL version number are consistent, both in your project's references and in the web.config file. Note that if you have a reference selected, you can toggle the "SpecificVersion" property to True in the Properties panel; presumably this makes .NET more picky as to which DLL version it chooses.