I had a similar problem (with the optional The "BuildShadowTask" task failed unexpectedly message) with a project originally developed with VS2010, and I had to spend the last few hours exploring yet another inherited aspect of the build process.
There is a good chance that you are dealing with a private accessor file ( .accessor ) that was deprecated in VS2012 ( source - 404). This was preceded by an announcement from the VS2010 team that they no longer worked on these features.
There is also the possibility that you are simply dealing with erroneous links to the wrong version of UnitTestFramework, but NuGet recovery should fix this. If not, see this GitHub thread for a possible fix (manually change the ref to the shared folder) or go to the new MSTest.TestAdapter and MSTest.TestFramework (see the MSDN support thread ).
Decision
- Edit unit test
.csproj and change the item links from <Shadow Include="Test References\namespace.accessor" /> to <None Include="Test References\namespace.accessor" /> ( Shadow => None ). - Even better, just delete all
.accessor files from the unit test of the Test References project.
Ideally, you also rewrite your unit tests to remove references to private methods, either by re-archiving to separate the problems, or by changing the properties to internal and using "friend" using InternalsVisibleToAttribute .
For those who, for some reason, continue to support testing of private methods, the same post provides the following logical questions, "What is available for me then?" :
For those who want to continue testing the internal APIs, you have three options:
- Use the Microsoft.VisualStudio.TestTools.UnitTesting.PrivateObject class to help access internal and private APIs in your code. This can be found in the Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll assembly.
- Create a reflection infrastructure that can mirror your code to access internal or private APIs.
- If the code you are trying to access is internal, you can access your APIs using InternalsVisibleToAttribute so that your test code can access the internal APIs.
However, there is no good replacement for Code Generation for new features added by lanugage commands. You can create TestMethod stubs and then remove the internal code. You only need to save the stub.
Further readings / sources that helped me put this together:
brichins
source share