41

When trying to open an older solution in VS2017 there is an old Unit Test project that is giving me a problem when building.

I keep getting the following error when building this test project:

Could not load file or assembly 'file:///C:\Projects\MyProj\Test\DAL\UnitTestProj\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll' or one of its dependencies. The system cannot find the file specified.

I checked the project's references and it appears to be referencing Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll. Additionally there are no code errors. How could I ever figure out if it is one of its dependencies that it can't find?

Peter Szekeli
  • 2,712
  • 3
  • 30
  • 44
Blake Rivell
  • 13,105
  • 31
  • 115
  • 231
  • 1
    Well, does `C:\Projects\MyProj\Test\DAL\UnitTestProj\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll'` actually exist there? Come to think of it, *why* the heck is it there in the first place? Remove the reference and add it back using the Assemblies tab of the reference manager. Don't browse to a DLL on disk. –  Jun 13 '17 at 15:18
  • 1
    @Will I was thinking the same thing... is it actually trying to find it in my project's directory? I already tried removing it then going to the reference manager > Extensions then there are about 5 duplicates of Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll available to reference. When referencing I keep getting the same error... Not sure what the heck could be telling the project to look in C:\Projects\MyProj... to find the dll... I don't see it when I go to References > Assemblies.. only Extensions has it. – Blake Rivell Jun 13 '17 at 15:22
  • 1
    Yeah, extensions. Odd. I see the one that's working with my tests is C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll You know, you can always create a new test project, move your classes over manually and ditch the botched project file... –  Jun 13 '17 at 15:27
  • @Will This is the strangest thing.. Even after re-referencing the assembly through Microsoft Visual Studio 14.0\Common7\IDE\ReferenceAssemblies... It still keeps erroring saying it is looking for it in the project's directory. – Blake Rivell Jun 13 '17 at 15:27
  • @Will This is what I might do, but then I can't stand dealing with Source Control when it comes to things like this.. Additionally, I kind of want the Test project to be the same old version it always was since it is a project I didn't create. – Blake Rivell Jun 13 '17 at 15:28
  • Another alternative is to create a new test project, add the files manually but add them as links (so they exist in the original project), and get that second test project working. Once verified it works fine, unload both and compare the botched one with the working one. There may be some handmade deviltries inside the csproj that's screwing things up. –  Jun 13 '17 at 15:31

6 Answers6

79

I had a similar issue (with the additional message The "BuildShadowTask" task failed unexpectedly) with a project originally developed with VS2010, and got to spend the last few hours learning about yet another legacy facet of the build process.

There is a good chance that you are dealing with private accessor files (.accessor), which were deprecated in VS2012 (original source). This was foreshadowed in an announcement from the VS2010 team that they were no longer working on these features.

There is also a chance you're just dealing with erroneous refs to the wrong version of UnitTestFramework, but a NuGet restore should fix this. If not, see this GitHub thread for a possible fix (manually change the ref to the public folder), or move to the new MSTest.TestAdapter and MSTest.TestFramework packages (see MSDN support thread).

Solutions

A. Edit the unit test .csproj and change the item Include references from Shadow => None: <Shadow Include="Test References\namespace.accessor" /> to
<None Include="Test References\namespace.accessor" />

B. Better yet, simply delete all the .accessor files from the unit test project's Test References folder.

Ideally, you would also rewrite your unit tests to remove references to private methods, either by re-architecting to separate concerns or by changing properties to internal and using "friend" with the InternalsVisibleToAttribute.

For those who need to continue supporting testing of private methods for some reason, the same post provides the following suggestions to the logical question "What is available for me then?":

For those who wish to continue testing internal APIs, you have three options:

  1. Use the Microsoft.VisualStudio.TestTools.UnitTesting.PrivateObject class to assist in accessing internal and private APIs in your code. This is found in the Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll assembly.
  2. Create a reflection framework that would be able to reflect off your code to access internal or private APIs.
  3. If the code you are trying to access is internal, you may be able to access your APIs using the InternalsVisibleToAttribute so your test code can have access to the internal APIs.

However, there is not any good replacement for Code Generation for the new features added by the lanugage teams. You may create the TestMethod stubs and then remove the internal code. You only need to keep the stub itself.

Further reading / sources that helped me piece this together:

brichins
  • 3,825
  • 2
  • 39
  • 60
6

Right click the project references folder. Add reference > Assemblies > extensions. Check Microsoft.VisualStudio.QualityTools.UnitTestFramework 10.1, and uncheck any older version.

John H
  • 502
  • 6
  • 9
  • There isn't such entry in the Assemblies > Extensions... (in fact, there's none)... where do you find this dll? It can't be added directly through nuget... – veljkoz Apr 07 '19 at 12:21
  • This is the solution – hyankov Jun 13 '19 at 13:51
  • Added the new reference, but I still get "The system cannot find specified file" error – null canvas Jun 13 '19 at 21:01
  • 1
    Didn't work for me. Had to go with brichin's answer instead. VS 2019. – Zoomzoom Jun 21 '21 at 19:02
  • For some reason, my install has 3 different "versions", two of which are 10.0, but are located in two different folders in VS2019. One is in "PublicAssemblies", the other is "ReferencedAssemblies". I changed it to "PublicAssemlies" rebuilt, and the DLL appears in the bin file and solved the problem – LarryBud Jul 11 '21 at 10:16
0

This is related to Visual studio Enterprise 2015, add new load test was failing: and spiting as "Unable to find assembly 'Microsoft.VisualStudio.QualityTools.LoadTest, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"

Due to Assembly installed in public assemblies shows as version 10.0.0.0 which is missed in GAC,

GAC had only 10.1.0.0. Once GAC updated with 10.0.0.0 and restart VS 2015. should resolve the issue similar to this.

Some more detail for better reasoning, System Assembly path and project path DLL path ......\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\PublicAssemblies\Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll

.CSProj reference version

dhandapani harikrishnan
  • 17
  • 4
  • 2
    Maybe you can clarify why you think this solves the problem in the question, and clarify what steps you think needs to be taken. Note that you can format your examples so it is clear what is explanation and what is a pathname. –  Feb 04 '19 at 20:23
  • "Once GAC updated with 10.0.0.0"... If only you'd said how you managed to DO that. My problem is that it's refusing to start a compiled program. I could _probably_ successfully recompile it, but then I couldn't guarantee that it's the same as the old version. – Auspex Nov 03 '20 at 13:42
0

I had a same issue while I was upgrading project to .Net4.8 in Visual studio 2022 earlier we were using Visual studio 2017.

Error:
The "BuildShadowTask" task could not be loaded from the assembly ***\Microsoft.VisualStudio.TestTools.BuildShadowsTask.dll. Could not load file or assembly 'file:///***Microsoft.VisualStudio.TestTools.BuildShadowsTask.dll' or one of its dependencies.

Solution : I removed ".accessor" files from project as that is being used for accessing private methods(most probably accessor is depricated). Then we used "PrivateObject" class for accessing private members in UnitTest. Later we updated Unit Test case. Code references could be found from below articles.

Unit test private methods?

Unit Testing: Exposing Private Members

0

I had a similar issue (compile project in server Jenkins)

Solution: Include VS.QualityTools.UnitTestFramework to reference project, whit Pakage Manager: PM>NuGet\Install-Package VS.QualityTools.UnitTestFramework -Version 15.0.27323.2 https://www.nuget.org/packages/VS.QualityTools.UnitTestFramework

GastonGmz
  • 1
  • 1
-3

Try to fully uninstall Visual Studio 2017 (not repair). Then download the latest version and install it. Remember to check if MSBuild is added to installation files. Remember to delete folder inside Documents: Documents\Visual Studio 2017. In my case, this simple solution fixed all errors.

Adrian Mar
  • 1
  • 2