We Keep Coding

Nuget package not found after restore VS 2019 16.5.0

I've been fighting with nuget all morning, trying to get a solution that builds in the UI AND from the command line. Here's the latest problem, which I haven't made any headway on:
I'm running nuget restore on the solution file. This works, all referenced packages are restored - I can see the files in the /packages folder under the solution folder.
I'm building with devenv command line - I have to because this solution contains project types that msbuild doesn't support.
The first project that references a nuget package, fails to compile with ...cs(3,7,3,17): error CS0246: The type or namespace name 'Newtonsoft' could not be found (are you missing a using directive or an assembly reference?)
The project builds (and rebuilds, and rebuilds with the package folder cleared out) just fine in the UI, but the command line build isn't seeing the restored packages.
The build that's failing is in a CLEAN folder on the same computer where I'm doing the UI build, so it's get from source control, nuget restore, devenv build.
Things I've tried
Looking for bad hint paths in the project file (saw this in another question/answer). These references don't appear in the project file at all - trying to add them produces an error saying that the reference can't be added because it's already added automatically by the build system.
Verifying that files do exist after restore.
Doing the same steps from a command line in the SAME folder where the UI is building. This works fine.
What am I missing? this shouldn't be so hard..
UPDATE: The solution consists of 14 projects: 9 C# class libraries, 2 c# applications, 1 reporting services project and 2 WiX installer projects. All C# projects target Net472, NOT Core. The key part of the solution structure appears to be:
Project A references
Newtonsoft.Json via nuget
Project B references
Project A
Newtonsoft.Json via nuget
Other packages via nuget
During build, project B fails to compile due to the lack of a reference to Newtonsoft.Json. Project A and all of the other nuget packages are supplied to the compier as references. Again, all nuget packages are in fact restored - Project A finds Newtonsoft.Json, project B does not.
In the detailed msbuild log output, this is the only mention of Newtonsoft.Json in the build of project 10 (Project B above):
10> Dependency "Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed".
10> Resolved file path is "...ProjectA\bin\Release\Newtonsoft.Json.dll".
10> Reference found at search path location "...ProjectA\bin\Release".
10> For SearchPath "...ProjectA\bin\Release".
10> Considered "...ProjectA\bin\Release\Newtonsoft.Json.winmd", but it didn't exist.
10> Required by "...ProjectA\bin\Release\ProjectA.dll".
10> Required by "C:\...ProjectA2\bin\Release\ProjectA2.dll".
10> Found related file "...ProjectA\bin\Release\Newtonsoft.Json.xml".
10> The ImageRuntimeVersion for this reference is "v4.0.30319".
(Folder and project names have been obscured)

A couple things going on here, finally got a solution that works. Why this built in the IDE is anyone's guess - it's adding some extra secret sauce to make things work (more than just the automatic nuget restore).
I tried changing all projects to use PackageRef instead of packages.config. That caused nuget restore to fail with an obscure msbuild error that I didn't try to diagnose.
I noticed that SOME of the nuget packages were referenced in the .csproj files with ordinary Reference elements, but some of them were not (specifically, Newtonsoft.Json in "Project B" - and some others that I hadn't noticed due to B failing).
To correct the situation:
Remove ALL use of PackageRef elements - change back to packages.config in ALL projects
Make sure the each of the nuget -provided DLLs is referenced in the .csproj files. You have to do this by editing the csproj file by hand - the IDE won't let you add the missing references.
I'm assuming that this is a temporary situation and that in the long run the solution will be to use PackageReference everywhere.

you already checked the files app.config and packages.config, and the dotnet framework version?

Nuget package not found after restore VS 2019 16.5.0
devenv /build command line does not have the job to restore nuget packages by default. However, there are such options in VS IDE so that it will restore packages first and then build. But these do not work in command line.See this similar issue.
But you still want to use devenv to build your project and since you use a framework project with packages.config, I suggest you could use nuget.exe.See this.You can try these:
1) download nuget.exe from this link and then configure its local address to PATH in the environment variable and make sure that you can call nuget from CMD.
2) open vs command prompt, cd the path of the solution and then type this first:
nuget restore
Then you can type your devenv command line and I am sure that this will execute without any errors.
devenv xxxx.sln /rebuild
Besides,you can add a custom target in any xxx.csproj file of your solution like this:
<Target Name="restoresolution" BeforeTargets="BeforeBuild">
<PropertyGroup>
<nugetpath>C:\tools</nugetpath> /////the local path of the nuget.exe
</PropertyGroup>
<ItemGroup>
<slns Include="$(MSBuildProjectDirectory)\..\**\*.sln" />
</ItemGroup>
<Exec command="$(nugetpath)\nuget restore %(slns.Identity)" />
</Target>
Then you can run devenv xxxx.sln /rebuild directly.

MSBuild is replacing Newtonsoft.Json.dll with an older version

I am using the MSBuild runner in TeamCity to build an ASP.net web api and running unit tests. Everything was working, until I upgraded to "Microsoft Build Tools 2017 15.7.2".
Suddenly msbuild was copying an older version of Newtonsoft.Json.dll (version 6.0.4.17603) from either "C:\Program Files (x86)\ISS\Microsoft Web Deploy V3" or "C:\Program Files\ISS\Microsoft Web Deploy V3" to the output folder when building the solution. All the projects are referencing the 9.0.1 version using NuGet.
Monitoring the output folder as the build was running, I could see the .dll switching back and forth between 6.0.4 and 9.0.1 until the build ended, and the 6.0.4 version remained.
I found this question and when I renamed the Newtonsoft.Json.dll files in the Web deploy folders to Newtonsoft.Json_old.dll", msbuild did not replace my 9.0.1 version and everything was working fine.
I have checked that all the projects referencing to Newtonsoft.Json are referencing the 9.0.1 version and using the correct Hint-Path in .csproj files.
Does anyone have any idea how to solve the problem? My solution seems more like a workaround and I would like to know why msbuild was copying this file in the first place.

Summary
When MSBuild is resolving assemblies, it will search in some pretty weird directories, including that Web Deploy folder, depending on what you have installed. Based on the MSBuild reference, I believe that this is legacy behavior. You can stop it from doing that with an MSBuild property defined in your project file.
In the affected project file, find the following line:
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
And add this below it:
<PropertyGroup>
<AssemblySearchPaths>$(AssemblySearchPaths.Replace('{AssemblyFolders}', '').Split(';'))</AssemblySearchPaths>
</PropertyGroup>
This will cause MSBuild to no longer look in the problematic folders when resolving assemblies.
Full Story
My team ran into a similar problem when we moved to Visual Studio 2019. Some of our projects are still targeting .NET Framework 4.0, and after installing Visual Studio 2019 on our build agents, we started getting a mysterious error with projects that referenced some of our core libraries:
The primary reference "OurCoreLibrary, Version=3.4.2.0, Culture=neutral, PublicKeyToken=xxxxxxxxxxxxxxxx, processorArchitecture=MSIL" could not be resolved because it has an indirect dependency on the assembly "Newtonsoft.Json, Version=9.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed" which was built against the ".NETFramework,Version=v4.5" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.0".
The problem went away upon switching the project to target 4.5, but for reasons I won't get into here, we couldn't do that for every affected project, so I decided to dig in a bit deeper.
As it turns out, your question offered some insight into what was going on. The version of Newtonsoft.Json that we were referencing matched the version in "C:\Program Files (x86)\IIS\Microsoft Web Deploy V3", and when I removed the file, the build succeeded.
Our specific problem was that the copy of Newtonsoft.Json in the Web Deploy folder was the same version (9.0.0.0) but the wrong framework (4.5 instead of 4.0), and for whatever reason the resolution logic doesn't check the target framework, causing a mismatch at build time. Updating to VS2019 involved updating Web Deploy, which also updated that copy of Newtonsoft.Json to 9.0.0.0, causing our collision.
To see why that assembly was even being looked at to begin with, I set the MSBuild project build output verbosity to Diagnostic and took a look at what was happening. Searching for the offending path showed that in the ResolveAssemblyReferences task, MSBuild was going through some unexpected places to find matches:
1> For SearchPath "{AssemblyFolders}". (TaskId:9)
1> Considered "C:\Program Files (x86)\Microsoft.NET\ADOMD.NET\140\OurCoreLibrary.winmd", but it didn't exist. (TaskId:9)
1> Considered "C:\Program Files (x86)\Microsoft.NET\ADOMD.NET\140\OurCoreLibrary.dll", but it didn't exist. (TaskId:9)
1> Considered "C:\Program Files (x86)\Microsoft.NET\ADOMD.NET\140\OurCoreLibrary.exe", but it didn't exist. (TaskId:9)
1> Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.0\OurCoreLibrary.winmd", but it didn't exist. (TaskId:9)
1> Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.0\OurCoreLibrary.dll", but it didn't exist. (TaskId:9)
1> Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.0\OurCoreLibrary.exe", but it didn't exist. (TaskId:9)
1> Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\OurCoreLibrary.winmd", but it didn't exist. (TaskId:9)
1> Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\OurCoreLibrary.dll", but it didn't exist. (TaskId:9)
1> Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.5\OurCoreLibrary.exe", but it didn't exist. (TaskId:9)
1> Considered "C:\Program Files\IIS\Microsoft Web Deploy V3\OurCoreLibrary.winmd", but it didn't exist. (TaskId:9)
1> Considered "C:\Program Files\IIS\Microsoft Web Deploy V3\OurCoreLibrary.dll", but it didn't exist. (TaskId:9)
1> Considered "C:\Program Files\IIS\Microsoft Web Deploy V3\OurCoreLibrary.exe", but it didn't exist. (TaskId:9)
1> Considered "C:\Program Files (x86)\Microsoft SQL Server\140\SDK\Assemblies\OurCoreLibrary.winmd", but it didn't exist. (TaskId:9)
1> Considered "C:\Program Files (x86)\Microsoft SQL Server\140\SDK\Assemblies\OurCoreLibrary.dll", but it didn't exist. (TaskId:9)
1> Considered "C:\Program Files (x86)\Microsoft SQL Server\140\SDK\Assemblies\OurCoreLibrary.exe", but it didn't exist. (TaskId:9)
Further digging shows that the paths searched are passed in as AssemblySearchPaths, which is defined in Microsoft.Common.CurrentVersion.targets:
<AssemblySearchPaths Condition=" '$(AssemblySearchPaths)' == ''">
{CandidateAssemblyFiles};
$(ReferencePath);
{HintPathFromItem};
{TargetFrameworkDirectory};
$(AssemblyFoldersConfigFileSearchPath)
{Registry:$(FrameworkRegistryBase),$(TargetFrameworkVersion),$(AssemblyFoldersSuffix)$(AssemblyFoldersExConditions)};
{AssemblyFolders};
{GAC};
{RawFileName};
$(OutDir)
</AssemblySearchPaths>
According to the MSBuild Task Reference for the ResolveAssemblyReferences task, SearchPaths parameter is defined as:
Specifies the directories or special locations that are searched to find the files on disk that represent the assemblies. The order in which the search paths are listed is important. For each assembly, the list of paths is searched from left to right. When a file that represents the assembly is found, that search stops and the search for the next assembly starts.
...and it defines a few special constants, including our friend {AssemblyFolders}:
{AssemblyFolders}: Specifies the task will use the Visual Studio.NET 2003 finding-assemblies-from-registry scheme.
Because the directories are checked in order, you might expect {HintPathFromItem} to take precedence, and in most cases it does. However, if you have a dependency with a dependency on an older version of Newtonsoft.Json, there won't be a HintPath for that version and so it will continue on until it resolves.
Later on in Microsoft.Common.CurrentVersion.targets we can see that there are cases where this constant is explicitly removed, which is where the answer above comes from:
<PropertyGroup Condition="'$(_TargetFrameworkDirectories)' == '' and '$(AssemblySearchPaths)' != '' and '$(RemoveAssemblyFoldersIfNoTargetFramework)' == 'true'">
<AssemblySearchPaths>$(AssemblySearchPaths.Replace('{AssemblyFolders}', '').Split(';'))</AssemblySearchPaths>
</PropertyGroup>
Removing this constant removes the offending folders from consideration, and to be honest I cannot think of a situation where I would want an assembly to implicitly resolve to whatever version of say, Newtonsoft.Json, was hanging out in the Web Deploy or SQL Server SDK folder. That being said, I am sure there's a case out there where turning this off will cause somebody issues, so keep that in mind.

It may be worth to trigger a custom build and ticking 'clean all files in the checkout directory before the build' - you may have conflicting build tools lingering.

I found another simple solution. I manually moved
<Reference Include="Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL">
<HintPath>..\packages\Newtonsoft.Json.12.0.3\lib\net45\Newtonsoft.Json.dll</HintPath>
</Reference>
to the last ItemGroup section with Reference.

MsBuild does not find restored NuGet-Packages on Visual Studio Online

I try to build a solution stored in an external GIT-Repository on Visual Studio Online.
It has the following steps:
1: Git Restore - Works
2: NuGet Restore - Works
3: Build - Does NOT work
My first guess when looking at the logs is that MsBuild is not looking for the Packages where NuGet had stored them.
Some Lines from NuGet Restore:
2018-03-14T21:10:11.0352862Z Completed installation of AngleSharp 0.9.9
2018-03-14T21:10:11.0353230Z Adding package 'AngleSharp.0.9.9' to folder 'D:\a\1\s\packages'
2018-03-14T21:10:11.0353563Z Added package 'AngleSharp.0.9.9' to folder 'D:\a\1\s\packages'
2018-03-14T21:10:11.0354972Z Added package 'AngleSharp.0.9.9' to folder 'D:\a\1\s\packages' from source 'https://api.nuget.org/v3/index.json' 'Microsoft.SharePointOnline.CSOM.16.1.7317.1200' to folder 'D:\a\1\s\packages'
Some lines from MsBuild:
018-03-14T21:10:21.2105399Z PrepareForBuild:
2018-03-14T21:10:21.2105793Z Creating directory "bin\Release\".
2018-03-14T21:10:21.2424947Z Creating directory "obj\Release\".
2018-03-14T21:10:30.3569560Z ResolveAssemblyReferences:
2018-03-14T21:10:30.3570425Z Primary reference "AngleSharp, Version=0.9.9.0, Culture=neutral, PublicKeyToken=e83494dcdc6d31ea, processorArchitecture=MSIL".
2018-03-14T21:10:30.3670272Z ##[warning]C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets(2041,5): Warning MSB3245: Could not resolve this reference. Could not locate the assembly "AngleSharp, Version=0.9.9.0, Culture=neutral, PublicKeyToken=e83494dcdc6d31ea, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
My solution/packages structure is:
....\mysolution\myproject\myproject.csproj
....\mysolution\myproject\packages.config
Current Config:
So how can I change the Nuget and/or msbuild-behavior to make this work?
(Update): To clear this up: I have this problem with every package. They all are in the packages.config, each one is downloaded from Nuget, but each one also isn't found from MsBuild
(Update2) The Commands generated are currently the following:
NUGET:
D:\a\_tool\NuGet\4.4.1\x64\nuget.exe restore D:\a\1\s\AweCsomeO365\packages.config -PackagesDirectory D:\a\1\a\packages -Verbosity Detailed -NonInteractive -ConfigFile D:\a\1\Nuget\tempNuGet_22.config
MSBUILD:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\msbuild.exe" "D:\a\1\s\AweCsomeO365\AweCsomeO365.csproj" /nologo /nr:false /dl:CentralLogger,"D:\a\_tasks\VSBuild_(GUID)\1.126.0\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll";"RootDetailId=(GUID)|SolutionDir=D:\a\1\s\AweCsomeO365"*ForwardingLogger,"D:\a\_tasks\VSBuild_(GUID)\1.126.0\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll" /p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation=D:\a\1\a /p:ReferencePath=D:\a\1\a\packages /p:platform="anyCPU" /p:configuration="Release" /p:VisualStudioVersion="15.0" /p:_MSDeployUserAgent="VSTS_(GUID)_build_4_22
I replaced the GUIDs; tempNuGetConfig is something that seems to be generated by VSTS dynamically
Still. even if the log states that nuget stores the packages
Added package 'AngleSharp.0.9.9' to folder 'D:\a\1\a\packages'
MsBuild does not seem to find them there:
For SearchPath "D:\a\1\a\packages".
2018-03-16T13:57:42.4625155Z Considered "D:\a\1\a\packages\AngleSharp.winmd", but it didn't exist.
2018-03-16T13:57:42.4625456Z Considered "D:\a\1\a\packages\AngleSharp.dll", but it didn't exist.
2018-03-16T13:57:42.4625730Z Considered "D:\a\1\a\packages\AngleSharp.exe", but it didn't exist.
VSTS-Configurationvalues:
MsBuild: /p:ReferencePath=$(Build.StagingDirectory)\packages
Nuget-DestiantionDirectory: $(Build.StagingDirectory)\packages
(update3): I have no solution file, but only a csproj-file in that repository

The issue was that inside the project there was a hintpath for the packages directing to a location that was not within the GIT-Repository (and shouldn't):
<Reference Include="AngleSharp, Version=0.9.9.0, Culture=neutral, PublicKeyToken=e83494dcdc6d31ea, processorArchitecture=MSIL">
<HintPath>..\..\AweCsome365Test\packages\AngleSharp.0.9.9\lib\net45\AngleSharp.dll</HintPath>
</Reference>
My original approach was to define a target directory to NuGet and a Source Directory for MSBuild to use another location to the packages that both understand.
The issue though (as far as I understand) is, that NuGet always creates a subfolder-structure "./packages/{PackagesName}/lib/net45/{file}" and MSBuild does not look recursivly when setting "./packages" as source path.
The above is just an explanation for the future guy running into the same problem
So my solution was to mimic the local behavior for nuget and changing the output directory to match the HintPath (even if there is no "AweCsome365Test")-directory in the repository:
(I will leave this question open as this solution smells fishy. If anyone has a better solution that allows to chain nuget and msbuild without using the HintPath I am happily willing to spend my bounty on it)

I believe that your MSBuild "ReferencePath" parameter is not correct. you are telling MS Build that all your references (nuget packages and their dlls included) are going to be located at "D:\a\1\a\packages" but that is not where nuget will download and store the packages and dlls. Nuget will download and extract files into D:\a\1\a\packages\{packageName}\{version}\lib\{environment}\package.dll. I think you need to remove that last parameter (ReferencePath) from your MSBuild arguments.
I also noticed that your PackageLocation parameter is not the same as the destination for the NuGet restore task, do you need to add the "\packages" to that parameter like the destination in the restore task?

Change the nuget restore destination directory to $(Build.SourcesDirectory)\packages and remove the msbuild ReferencePath parameter.

The answers here are largely right. However it's worth noting another cause that can result in this behaviour. My toolchain was using Azure DevOps which is basically the same as Visual Studio Online, just a few years later.
Cause:
Reference your project from a different solution (cross-repo), for instance for debugging purposes
Update NuGet references in the problematic project from the external place you referenced it from
What this does is make use of the solution location for packages when the package gets installed.
For .Net core/standard projects, using Update-Package -reinstall appears to fix things. However, for .Net Framework projects, even though packages.json may get rebuilt, the <HintPath /> node in the .csproj gets left as is - with a reference to a packages folder that Azure will never create.
Simple fix:
Right click on the offending solutions locally, and choose Unload
Right click on the unloaded project, choose edit .csproj
Find any hintpaths that look like ../../OtherRepo/packages (the slash in use may vary), and change them to ../packages
Confirm the solution does build locally still
Push the changes to Azure, and cross your fingers
This approach will fix the issue caused by consolidating / updating packages from the wrong place rather than requiring a change to the build pipeline to spoof that location (which in may case, wasn't working very well either).

MSBuild not resolving references pointing outside of GAC

I am new to C# so it may be possible that I am not asking the right questions. Please bear with me.
I have a solution and within that solution is a project that is executing an SSIS package remotely. After some research I discovered that in order to do so I needed to create some references to DLLs that were "outside" of the GAC (General Assembly Catalog ?). The following assemblies were referenced:
C:\Windows\assembly\GAC_MSIL\Microsoft.SqlServer.Management.IntegrationServices\11.0.0.0__89845dcd8080cc91\Microsoft.SqlServer.Management.IntegrationServices.dll
C:\Program Files (x86)\Microsoft SQL Server\110\SDK\Assemblies\Microsoft.SqlServer.Management.Sdk.Sfc.dll
C:\Program Files (x86)\Microsoft SQL Server\110\SDK\Assemblies\Microsoft.SqlServer.Smo.dll
When I clean and build the solution from within Visual Studio 2015, everything builds fine. However when I call MSBuild on the solution from my deployment script, I get many errors saying that the references do not exist. For example, here is one of those errors:
"C:\TestModule\SSISTests\SSISTests.csproj" (default target) (10) -> (CoreCompile target) -> SSISTests.cs(78,17): error CS0012: The type 'Microsoft.SqlServer.Management.Common.ISfcConnection' is defined in an assembly that is not
referenced. You must add a reference to assembly 'Microsoft.SqlServer.ConnectionInfo, Version=11.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91'. [C:\TestModule\SSISTests\SSISTests.csproj]
Is there an option I am not passing to MSBuild that would solve this problem? This is not a dependency issue (I don't think) because no other projects are needed by this project - just these SQL Server assemblies.

Open your csproj file and check to see if that DLL is correctly referenced. Also, see if you can run MSBuild against just the csproj and not the sln. Might be a pathing issue.

Different .NET build result when run in Bamboo

I am building a .net 4.5.2 application using Atlassian Bamboo. The build has been operating fine with dependencies on Telerik.Windows.Controls.Data for several weeks.
On a recent feature branch I have added a dependency on Telerik.Windows.Controls.GridView.dll version 2015.3.1104.45. Now the build is failing.
warning MSB3245: Could not resolve this reference. Could not locate
the assembly "Telerik.Windows.Controls.GridView,
Version=2015.3.1104.45, Culture=neutral,
PublicKeyToken=5803cfa389c90ce7, processorArchitecture=MSIL". Check to
make sure the assembly exists on disk. If this reference is required
by your code, you may get compilation errors. 24-Dec-2015 08:11:23
error MC3074: The tag 'RadGridView' does not exist in XML namespace
'http://schemas.telerik.com/2008/xaml/presentation'. Line 55 Position
18.
As is traditional when builds fail, I followed these triage steps:
Checkout the offending commit and test build on my workstation
If it "works on my machine™", log in to the build server and test build using the working directory that failed
I build both steps in the visual studio 2015 IDE. In this instance - both builds succeed. Frustrating! So I take to the command line and build the solution using the command line executed by Bamboo:
call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.com" "SolutionNameRedacted.sln" /rebuild Release
This also succeeds!
I noticed the following line in the bamboo log:
24-Dec-2015 08:10:23
C:\Atlassian\Data\Bamboo\xml-data\build-dir\CS-CC13-JOB1>call
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat"
amd64 24-Dec-2015 08:10:23 '"C:\Program Files (x86)\Microsoft Visual
Studio 14.0\VC\vcvarsall.bat"' is not recognized as an internal or
external command,
This batch file is used to specify the compiler toolset. Is it a problem that it is not found? I always assumed compiler preferences were expressed by the project files. I have checked the Microsoft Visual Studio 14.0 directory and vcvarsall.bat does not exist anywhere.
The only significant change to the csproj file since it last built is the addition of this line:
<Reference Include="Telerik.Windows.Controls.GridView, Version=2015.3.1104.45, Culture=neutral, PublicKeyToken=5803cfa389c90ce7, processorArchitecture=MSIL" />
I am at a bit of a loss as it is causing delivery to slip massively.
My current theory is that it is a user account issue and bamboo does not have access the to Telerik assembly it needs. My next steps are too:
References the assembly using clr-namespace in the xaml file that is breaking
Test the build on a user account with elevated permissions (sadly i don't have that kind of access)

As it turns out, Telerik do not install their binaries to the GAC. Visual Studio require a <hintpath> entry in the csproj file to help discovery. This path should be to you install directory.
Does this sound like a faff? It is abd I'm not terribly impressed. Thankfully the Telerik VS Extension will add the reference and hintpath for you. My recommendation is to always use this wizard.
The downside - all of your developers need the Telerik library installed in the same folder. I'm pretty sure you can manually register binaries with the GAC to skirt this.