We Keep Coding

Error MSB4062 after building solution with msbuild

I tried to build a solution with a script which uses msbuild.
In VS 2017 it worked perfectly fine, but unfortunately after moving project to computer with VS 2019 I am unable to build it this way.
In few projects of solution I am seeing the same error.
Error MSB4062
: The "CheckPathAttributes" task could not be loaded from the assembly C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v16.0\Web\Microsoft.Web.Publishing.Tasks.dll. Could not load file or assembly 'Microsoft.Build.Utilities.Core, Ve
rsion=15.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.

On your solution's folder, search for hidden .vs folder and delete the folder. Then open your VS 2019, open the solution, and do clean and rebuild.
Also looking at your error, it also may be caused by the fact that your script needs dependency to MSBUILD 15.0 but you are using VS 2019 and this means MSBUILD v16.0. I suggest you have to update your script as well.
Let me know if it works/solves your problem or not.

Why does changing valid SQL Server pipeline references in old projects cause the build to fail?

I'm currently trying to learn how to build custom SSIS components, a process for which the documentation is awful and awfully sparse. But then I stumbled on a treasure trove of open source components written in VS 2008 for SQL Server 2008. I figured downloading them and exploring how they work would be a fantastic learning opportunity.
They import into VS 2015 and build successfully without issue. But I don't want to test them against SQL Server 2008, which I don't have a copy of. I want them to work against SQL Server 2014.
In theory, this should be easy. Remove their references to the SQL Server SDK pipeline components in C:\Program Files (x86)\Microsoft SQL Server\100\SDK\ and change them to C:\Program Files (x86)\Microsoft SQL Server\120\SDK\ - and if you do this, the project doesn't complain at all.
Except the build fails: silently. No errors are produced in the error list but no dll's are produced either. Checking the output window reveals why:
error CS0246: The type or namespace name 'IDTSComponentMetaData100'
could not be found (are you missing a using directive or an assembly
reference?)
And there are various repetitions of that theme, depending on how many DLL's you've replaced. If you double click on one, it takes you to the offending line but VS 2015 doesn't flag the line as problematic. Indeed you can right-click on the offending class, "go to definition" and get a [from metadata] breakdown as you would for any valid reference.
Indeed for the simpler projects one can create a new project in Visual Studio 2015, add the references to the necessary dll's from SQL Server 2014 and then copy and paste the code in its entirety and it will build without complaint.
I have checked the csproj file and the references are updated to their expected versions.
<Reference Include="Microsoft.SQLServer.DTSRuntimeWrap, Version=12.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91, processorArchitecture=x86">
<SpecificVersion>False</SpecificVersion>
<EmbedInteropTypes>True</EmbedInteropTypes>
<HintPath>C:\Program Files (x86)\Microsoft SQL Server\120\SDK\Assemblies\Microsoft.SQLServer.DTSRuntimeWrap.dll</HintPath>
</Reference>
I've never seen VS behave like this before. What's going on, and how can I fix it?

Aha, worked it out.
The project was set to build against an old version of .Net which wasn't compatible with more recent versions of SQL Server. Changing the Target Framework in the project properties to the most recent version of .Net fixed the problem.
In this particular it uncovered another error saying the project was missing a reference to Microsoft.CSharp.RuntimeBinder.Binder.Convert. Adding a reference to Microsoft.CSharp fixed that one.

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.

Reference Microsoft.VisualStudio.QualityTools.UnitTestFramework for CI build

I have created a C# test project in VS2015 RC. it builds locally but when i attempt to build on our CI build server (TeamCity) it fails with errors:
UnitTest1.cs(2,17): error CS0234: The type or namespace name
'VisualStudio' does not exist in the namespace 'Microsoft' (are you
missing an assembly reference?)
[... .Tests.csproj]
UnitTest1.cs(9,10): error CS0246: The type or namespace name
'TestMethod' could not be found (are you missing a using directive or
an assembly reference?)
[... .Tests.csproj]
Clearly this is because the assembly containing these namespaces (Microsoft.VisualStudio.QualityTools.UnitTestFramework) is not on the build server; on my local machine it resides at C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll.
I could copy the assembly into my solution so that it becomes part of the codebase but manually moving files feels like a bit of an inelegant hack. I searched around on nuget and found http://www.nuget.org/packages/Microsoft.VisualStudio.QualityTools.UnitTestFramework/ which I figured would do the trick, but installing that package failed with:
Install-Package : Could not install package
'Microsoft.VisualStudio.QualityTools.UnitTestFramework 11.0.50727.1'.
You are trying to install this package into a project that targets
'.NETFramework, Version=v4.5.2', but the package does not contain any
assembly references or content files that are compatible with that
framework
What's my best option of solving this? I'm surprised that creating a test project in VS2015 does not automatically include all the dependencies that I need, though perhaps I'm being naive (I'm something of a fledgling dot netter).

The answer is similar to option 1 in eng.augusto's answer.
Microsoft doesn't provide NuGet for the latest version of Microsoft.VisualStudio.QualityTools.UnitTestFramework,
but rather supplies it as a part of Visual Studio
(normally at C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll)
I created the folder Microsoft.VisualStudio.QualityTools as a subfolder of my solution and copied:
Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll
Microsoft.VisualStudio.QualityTools.UnitTestFramework.xml
The files should be added to source control (even if DLLs are usually ignored).
Then I changed references in my Test.csproj to refer to a new location.

Hmm I have some ideas, so choose the one that best fits your needs
A simple answer should be mark the DLL to copy local and use a folder like Assemblies in the same folder of the solution and references "Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll"
Install Visual Studio in your build server. Sounds nuts but it's the closest to "developer machine" that you have.
Install the DLL in the GAC so you don't have to bother with this.
Fix the NuGet package (Adding a reference for the .NET Framework version) and use it.
Downgrade your .NET Framework version so you can use the NuGet package.
Create your own NuGet server! (and add the reference of the DLLs you need).
IMHO I'd choose the first answer, because it seems to be the "best way" to use NuGet to resolve all your packages problems but you are using a DLL that you don't know if it should be trusted.
In system used in "old" languages like C, or C++ it's common you download the source code and the libraries needed for the code to run so I do not think the NuGet package it's the best solution.
Using the first option you always have the same version and could check the MD5 of the file and know exactly what is running in your build server.
Maybe the real best option should be 6. When you use your own NuGet server to handle your DLLs making your live more awesome and trustable.

For projects created in VS 2017. Adding Nuget package Microsoft.VisualStudio.QualityTools.UnitTestFramework.Updated allows to build unit test projects on CI without VS installed on build server:

I was having this issue when trying to use MSBuild on our dev server via our CI/CD process after I was asked to uninstall VS2013 from our dev server by our IT team.
In my case in my build output there were a few lines with the word Considered. What this means is that the build is considering those folders for locations where the file may be located. One of those lines was as follows:
Considered "C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll", but it didn't exist.
I copied Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll from my local machine to that folder on the dev server and the error went away.

Of course Microsoft does a s...t job. To fix this, you need to copy the dll's to some convinint lication and reference them from your ptoject .csproj file.
<HintPath>..\packages\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll</HintPath>
</Reference>
</ItemGroup>
<ItemGroup>
<Reference Include="QualityTools-Fakes">
<HintPath>..\packages\Microsoft.QualityTools.Testing.Fakes.dll</HintPath>
</Reference>
</ItemGroup>
<ItemGroup>
I don't understand why when we add this from VSudio it does not update the same file instead no one has an idea what it does. In Java you have a single file pom.xml or build.gradle, nothing else. In C# there is all sorts of stuff which adds no value but confusion.

CefSharp.dll unresolved assembly reference

I'm currently making an extension for Spotfire that embeds a web browser (CefSharp) into the application. However, when I attempt to run the package, I get the error:
"Package 'D3Visualizations' has unresolved assembly references:
'CefSharp, version 1.25.4.0' is referenced by 'D3Visualizations.dll'."
I've added CefSharp.dll and CefSharp.WinForms.dll as references, and I have added those two as well as icudt.dll and libcef.dll into the bin/Debug folder.
I honestly don't know why it doesn't work right now; the last time I got an error in the package builder like this, it was due to .NET version mismatches.
What am I doing wrong? I'm using Visual Studio 2013 Express Desktop, and the project is in .NET framework 4.5.1.

Can you check the path for the references in their properties window? You can try removing and re-adding the references to the dlls in your bin folder and set Copy Local = true. If that doesn't work try setting it explicitly in the project file as in this question: Force VS to reference local dll