Develop Reference

Compile error on TFS - defined in an assembly is not referenced

We have a c# solution (framework 4.5.2), developed on a desktop, compiled on TFS server 2015. We added a new DLL project to it (framework 4.6.1), which uses the Microsoft Code Analysis package. The solution is being compiled with no problem on the desktop (VS 2017). We committed the changes to TFS, where it drops several compiler errors, e.g.:
The type 'ValueType' is defined in an assembly that is not referenced.
You must add a reference to assembly 'netstandard, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'.
The project contains several references according to word "netstandard":
<Reference Include="Microsoft.CodeAnalysis, Version=2.10.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<HintPath>..\packages\Microsoft.CodeAnalysis.Common.2.10.0\lib\netstandard1.3\Microsoft.CodeAnalysis.dll</HintPath>
</Reference>
<Reference Include="System.Collections.Immutable, Version=1.2.3.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL">
<HintPath>..\packages\System.Collections.Immutable.1.5.0\lib\netstandard2.0\System.Collections.Immutable.dll</HintPath>
</Reference>
When I added the the reference:
<Reference Include="netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" />
the compile errors still reported. On the desktop the solution still compiles without warnings or errors. What to do next?
PS: Unfortunately, the framework versions are mixed in the solution. The 4.5.2 is preferred, but there was no chance to add MS Code Analysis package to a dll project with this version. :( Is the multiple framework versions the root cause of the problem?

System.Web.Http / located assembly's manifest definition does not match the assembly reference

I'm not sure why am I getting this error now. I referenced an assembly out of Nuget package that is in turn referenced in packages.config file.
This is how the assembly is referenced in my csproj file:
<Reference Include="System.Web.Http, Version=5.2.3.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>..\..\packages\Microsoft.AspNet.WebApi.Core.5.2.3\lib\net45\System.Web.Http.dll</HintPath>
</Reference>
I tried to delete the reference in VS and re-reference it again from packages folder without any luck.
Following article mentiones GAC and appbase, but I'm not sure how to find those paths any why the compiler would even look there if the correct file is referenced in my csproj?
The located assembly’s manifest definition with name xxx.dll does not match the assembly reference

One more place to check was Web.config. As soon as version conflict was fixed there everything worked.
3 places to check for reference conflicts are:
*.csproj
packages.config
Web.config

Different publickeytoken for the same assembly

I have an assembly that is registered in GAC. In 'Windows/assembly' folder I can see it and also see its PublicKeyToken 'aaaa'. I have a SSIS solution (I think no matter at all what is the type of solution).
SSIS package has many c# scripts, each of them has its own references. Some of them contains reference for my assembly. I see the same path to the assembly in properties for it in each script. BUT one of the scripts has another PublicKeyToken 'bbbb' (the others have 'aaaa'). And it breaks the whole solution. Build works good, but Run fails. How can I manage such situation?
Update: issue appeared after new version of assembly has been added to the GAC. the old one has been deleted.
I tryed to change reference for a copy of dll but the problem doesn't go away. Maybe is there any way to set PublicKeyToken? I've even tryed to change compiled file (but what if? =))
In .dtsx file (file for compiled package) it looks like:
for one script:
<Reference Include="MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=bbbb, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>C:\assembly.dll</HintPath>
</Reference>
for the others:
<Reference Include="MyAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=aaaa, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>C:\assembly.dll</HintPath>
</Reference>

Visual studio 2012 project - Not able to load 'Newtonsoft.Json'

On running a windows phone project in VS 2012, I was getting this error:
{System.IO.FileNotFoundException: Could not load file or assembly 'Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The system cannot find the file specified.
File name: 'Newtonsoft.Json, Version=4.5.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'
at MobileConnection.SSCClient.SSCConnection.GetHostNameAndPort()
at MobileConnection.SSCClient.SSCConnection.InitializeSSCConnection(Boolean runningState)}
The corresponding entries in .csproj file is:
<Reference Include="Newtonsoft.Json">
<HintPath>..\packages\Newtonsoft.Json.4.5.11\lib\sl4-windowsphone71\Newtonsoft.Json.dll</HintPath>
</Reference>
And, in packages.config:
<package id="Newtonsoft.Json" version="4.5.11" targetFramework="wp80" />
I debugged it for a while, re-installed the newtonsoft.json package through nuget.
But the solution that worked for me is setting the 'private' property to 'True'.
Updated entry in .csproj file:
<Reference Include="Newtonsoft.Json">
<HintPath>..\packages\Newtonsoft.Json.4.5.11\lib\sl4-windowsphone71\Newtonsoft.Json.dll</HintPath>
<Private>True</Private>
</Reference>
I am not able to understand how it worked or what the issue was. The description on msdn documentation didn't help much either http://msdn.microsoft.com/en-us/library/vstudio/bb629388.aspx.

When running the program, it pulls in dlls from the output directory. Originally, Newtonsoft.Json wasn't being copied to the output directory, but by specifying Private to True, you told Visual Studio to copy the Newtonsoft.Json dll to the output folder along with your program.
For completeness, the documentation on Private:
Optional boolean. Specifies whether the reference should be copied to the output folder. This attribute matches the Copy Local property of the reference that's in the Visual Studio IDE.

Disk references not seen within build controller

I have various projects which reference assemblies within C:\Program Files (x86). I have installed the assemblies on my build controller in the exact same way and the files are in the C:\, however whenever I trigger a build my controller doesn't find the assemblies.
<Reference Include="GrapeCity.ActiveReports.Diagnostics.v7, Version=7.0.6163.0, Culture=neutral, PublicKeyToken=..., processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
</Reference>
The reference in the project looks like the above, which in my opinion I can understand why the build controller can't find the reference because there are no hint paths.
I have tried changing Copy Local to true and Specific Version to false, this also didn't work. What should I change in my project, build controller or build definition to make the server have scope of the assemblies?

So one way to solve this is to not reference from the GAC.
<Reference Include="GrapeCity.ActiveReports.Diagnostics.v7, Version=7.0.6163.0, Culture=neutral, PublicKeyToken=..., processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
</Reference>
Find this GrapeCity.ActiveReports.Diagnostics.v7.dll.
Where your .sln file resides, create a .\ThirdPartyReferences\ folder.
Copy GrapeCity.ActiveReports.Diagnostics.v7.dll to that directory.
Remove the "gac" reference.
Add the more local .\ThirdPartyReferences\ reference.
Check .\ThirdPartyReferences\ folder into source control.
Make sure .\ThirdPartyReferences\ is "pull down" from source control during the build.
OR
Get "GrapeCity.ActiveReports" installed on the build-server using their install tools.
Which should get into correctly into the GAC on the build server.
I usually choose the first option (my first option above).
I like having a very good handle on what my ThirdParty dependcies are for my build.