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?

Could not load file or assembly 'System.Runtime, Version=4.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

I got the project from colleague and got this error when building project:
Could not load file or assembly 'System.Runtime, Version=4.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
I guess this dll is in .NET Framework Dll Folder: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework, but after searching, I find many dll of other version, but I didn't find any System.Runtime.dll is 4.2.1.0.
Here's another similar question but no answer to it.
Is System.Runtime.dll 4.2.1.0 really exists in .NET Framework?

I know this is an old post, but I think it's useful to share my solution with others that encounter this exact problem.
I created a new Console App via the terminal: dotnet new console
I opened the folder of the Console App in Visual Studio 2019.
I tried to run the code using ctrl + f5
That's when I encountered: Could not load file or assembly 'System.Runtime, Version=5.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
To solve it, instead of opening the Console App folder in Visual Studio 2019, I had to open the file inside of it that ended with .csproj and then doing ctrl + f5. After that it ran smoothly. Hope this will help someone else. Been troubleshooting for a long time to find the solution.
TL;DR: open the .csproj file in Visual Studio 2019 instead of the project folder that it resides in.

This happens when you open the folder instead of the solution file. Simply ensure that you load the solution file and not the directory of your project.

This is quite an annoying issue. From what I noticed, it's being caused by dependentAssembly once you install a new package or update it. At least that was the root cause for me.
Try checking the dependentAssembly newVersion inside your Web.config. If I'm correct, you should have something like:
<dependentAssembly>
<assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.1.2.0" newVersion="4.3.0" />
</dependentAssembly>
Make sure that your Web.config dependentAssembly matches the version defined inside the Web.Base.config (or the version inside the Nuget Package Manager). If not, change the newVersion= to the version you have installed in your Nuget Package Manager.
If that doesn't work, you could check this link out. Might be an option which will work for you.

I had this problem today for System.Runtime 4.2.2.0. It happened when opening the folder for a solution in Visual Studio instead of opening the solution file instead. Closing Visual Studio 2019 down and clicking on the solution file to open it fixed my issue.

To solve the problem, I originally guess System.Runtime.dll should be in .NET Framework Dll Folder, because in Nuget Page of this dll, the version history doesn't contains 4.2.1.0, but after reading #Scircia answer, I try to add the latest Nuget System.Runtime.dll to the project by Right Click On Project > Property Page > References > Add. the Nuget version of the dll is 4.3.1, but its dll version is 4.6.27406.3.
After Adding, a new error show:
Assembly 'XXXX(It's secret), Version=x.x.x.x, Culture=neutral, PublicKeyToken=xx' uses 'System.Runtime, Version=4.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' which has a higher version than referenced assembly 'System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
But the dll I add is 4.6.27406.3, why got this 4.0.0.0 error? After some try, I finally find the main cause is, in the project many component use .NET Framework 3.5 so it should be run at 3.5, but when I Right Click On Project > Property Page > Build > Target Framework, it shows currently use 4.0.
So I follow these step to change the Target Framework from 4.0 to 3.5 Click OK, then again from 3.5 to 4.0, then the error is solved. That is, through 4.0 > 3.5 > 4.0, the web.config is auto modifed and seems some dll that need 3.5 is removed, become a real 4.0, and in Framework 4.0 the System.Runtime.dll works good.
Since it says need 4.2.1.0, but I add 4.6.27406.3 works, so I suppose that use a higer version than 4.2.1.0 is allowed, not need to use exactly 4.2.1.0.
But another point is, since the project need to run at 3.5 to make the Web UI package works, after changing to 4.0, some of the UI control lost function.
So I conclude that the XXXX(It's secret).dll should not be use in the .NET Framework 3.5 project.
Besides I use Resharper to see the XXXX.dll shows that it's .NETCoreApp.

My quick solutions was deleting the [application name].config file to make it ran.
It might be good enough if you only need to make the program run.

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.

Could not load file or assembly 'System.Web.Mvc, Version=5.2.3, Culture=neutral, PublicKey

After doing push from git server I got this error when I build and open my project:
Could not load file or assembly 'System.Web.Mvc, Version=5.2.3, Culture=neutral, PublicKeyToken=******' or one of its dependencies. The system cannot find the file specified.
The project is working pretty well with the same code in a different computer.

Problem
The error is a file not found, like the one I helped out with the other day:
Could not load file or assembly .. The system cannot find the file specified.
Troubleshooting
Open ProcessMonitor and run it when VS won't let you build your solution and throws the error. Stop the trace when it fails and investigate ProcMon's (Filemon) log to see where the IDE is looking for the DLL it cant find.
Solution
Put the DLL where its expected to be found (this will hopefully sort out the VS library referencing failure).
Also try:
disable Resharper
restart VS
clean & rebuild

I found nuget or some other update can bump the System.Web.MVC version to 4.0.0 unintentionally. So just check the dll that you have in your bin folder (or wherever the reference points) is of the same version specified in your web.config.

Visual Studio 2008: Cannot find reference to a project

We have an application wrote in C#, which broken into several projects. These projects have reference to others.
When someone gets the source from version control and opens the solution contains these projects on its own machine, Visual Studio cannot find the references between projects, even though referenced project is build successfully. That person have to re-add the reference to solve this.
Seems to me that Visual Studio keeps some data in `suo' file, so next time it knows where to find that re-added reference, and this problem won't appear next time the person opens the solution.
Since `suo' file keeps absolute path to references, we cannot commit it in our source control.
The problem is, We've got a separate machine, which builds this big application automatically (as our nightly-build releases) When the build-automation tool opens the solution, and calls Visual Studio's compiler to build it, the references cannot be find. (automation tool cleans everything, and get the latest version of the source again, so it dose not have `suo' file.)
Any solution?
Extra information
Visual Studio version: 2008 - 9.0.21022.8
.Net framework: 3.5 SP1
OS: Windows XP Professional (SP2 & SP3 - we have both of them)
Update
Seems that Visual Studio changes <ProjectReference> tag to <Reference> in `.csproj' files sometimes. Our developers commit the file, and this problem happens.
I couldn't find if it's a bug in Visual Studio. The only solution that comes into my mind is to write a tool to correct this in `.csproj' files, before pass it to the automation tool.

References are defined in the .csproj file for each project. They may be defined in one of two ways (in my experience).
Either with a hint path to find the referenced assembly:
<Reference Include="CommonServiceLocator.NinjectAdapter, Version=2.2.0.0, Culture=neutral, processorArchitecture=MSIL">
<HintPath>..\..\Dependencies\CommonServiceLocator.NinjectAdapter.dll</HintPath>
</Reference>
Or without one:
<Reference Include="CommonServiceLocator.NinjectAdapter, Version=2.2.0.0, Culture=neutral, processorArchitecture=MSIL"/>
You need to make sure that the references are in the first form, that the hint path exists, and that it's a relative path so that it works no matter where you check out the solution.
You can edit the .csproj files either with an external editor, or by right clicking the project, choosing "Unload project" from the context menu, then right clicking again on the unloaded project and choosing "Edit projectname.csproj". After you 're done editing, right click again and reload the project.

Open the project files (*.csproj) and look what are they referencing. Mostly sure the paths are relative to the solution path and your build script might use other paths.
One way of solving this:
Define an environment variable SOURCE_PATH that holds the path to your sources root folder
Edit the project files so they have reference relative to this path (use $(SOURCE_PATH)) in csproj files to reference it
Repeat steps 1-2 on each dev/build machine and add extra env variables if needed.
PS: The *.suo should not be in the version control system.

Why won't you use msbuild rather then automated visual studio compiler?

It's a bug in VisualStudio 2008 and before that.
If you open a solution that contains a project that have reference to another project, but referenced project doesn't included in the solution, VS finds the referenced project, but changes the reference in a way that it refers to the output DLL, not the project itself.
This bug is fixed in VS2010, and MSBuild 4.