We Keep Coding

VS Extension can't load Microsoft.TeamFoundation.Common

I have a Visual Studio extension that we use internally that I'm in the process of updating for Visual Studio 2022. The extension worked fine in previous versions of Visual Studio, but I've had to follow several steps to get it building and running for VS 2022. I've gotten to the point where it will build and run, but I'm getting an error at run time when I'm trying to create a TFS ticket in the extension (which is the main point of the extension).
On this line:
projectCollection = new TfsTeamProjectCollection(url, cred);
I get:
System.IO.FileNotFoundException
HResult=0x80070002
Message=Could not load file or assembly 'Microsoft.TeamFoundation.Common, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
Source=Microsoft.TeamFoundation.Client
Searching around a bit, it seems that there is a version of that assembly at C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer, but apparently you aren't allowed to add that to your project. Because when you try, Visual Studio will complain that:
A reference to 'Microsoft.TeamFoundation.Common' could not be added. This component is already automatically referenced by the build system.
Further searching reveals that that assembly is also included with the Microsoft.TeamFoundationServer.Client Nuget package (that I did have referenced in the original version of this extension but it was since removed somewhere along the line), but installing that did not fix the problem either (not with the version that used to work in previous versions of VS, or with the latest version available on NuGet)
I suspect that the problem is that there is a version of this assembly that is loaded by Visual Studio itself and is conflicting with the version that the extension is built again. But trying to add a bindingRedirect to app.config hasn't worked for me either (although maybe I don't have the version I'm redirecting to correct?).
Does anybody know the correct way to resolve this conflict?

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.

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.

Slow Cheetah transform failing

In Visual Studio 2012 I have Slow Cheetah version 2.5.10 installed. When building an app that uses Slow Cheetah, the build fails with the following error:
Error 1 The "SlowCheetah.Xdt.TransformXml" task could not be loaded
from the assembly
C:\Users\MyActiveDirectoryAccount\AppData\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10\SlowCheetah.Xdt.dll.
Could not load file or assembly
'file:///C:\Users\MyActiveDirectoryAccount\AppData\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10\SlowCheetah.Xdt.dll'
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. C:\Users\MyActiveDirectoryAccount\AppData\Local\Microsoft\MSBuild\SlowCheetah\v1\SlowCheetah.Transforms.targets
When navigating to this directory, I can see the Slow Cheetah files, but the SlowCheetah.Xdt.dll file is missing.
C:\Users\MyActiveDirectoryAccount\AppData\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10\
To triage this, I've:
Rebooted
Un-installed and re-installed Slow Cheetah
Clean and rebuild
None of the above fixed the problem. Any guidance would be appreciated. Thanks!

The answer is in one of the Q & A's (by zendu)
Copy the files from
%APPDATA%..\Local\Microsoft\MSBuild\SlowCheetah\v1.
to
%APPDATA%..\Local\Microsoft\MSBuild\SlowCheetah\v2.5.10.
List of files:
Install-Manifest.xml
Microsoft.Web.XmlTransform.dll
SlowCheetah.Tasks.dll
SlowCheetah.Transforms.targets
SlowCheetah.Xdt.dll
Source
Also see this related question
The "SlowCheetah.Xdt.TransformXml" task could not be loaded from the assembly

I had the same problem with Visual Studio 2010. I just install the SlowCheetah nuget package (install-package SlowCheetah) and after that the build succeed. The nuget package set up correctly the slowcheetah task in your solution.
SlowCheetah nuget Package