A weird thing started happening on my TFS build server recently. When it came time to run the unit tests, the build would fail with:
The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
For reference, here’s the standard testing step that was failing.. Note the “Test Assembly” parameter.. Nothing out of the ordinary there.
So I dug in.. The log file showed the error happening just after executing some vstest.ps1 Powershell file, but there was no other useful information. I then proceeded to hack up vstest.ps1 to include some additional logging until I discovered that the problem was occurring on this line:
Find-Files, eh? Problem is, Find-Files is in some Microsoft assembly referenced in the vstest.ps1 file. After quite a bit of searching with JustDecompile, I found the magic FindFiles class in Microsoft.TeamFoundation.DistributedTasks.Tasks.Common…
With a little bit of tweaking, I was able to get FindFiles working in LINQPad and test it with the same parameters that were being used during the build process…
Sure enough, it threw the exact same exception that I was seeing in my build process! I’ll spare you the details, but I eventually discovered that the path too long exception was happening because part of the build process was telling NPM to download all of its required modules for the project, and it was building a structure that looked like this..
It’s fascinating how some node/npm stuff was causing my .NET unit tests to fail, but you can’t deny the facts, folks!
Fortunately, I remember reading this article a couple weeks ago that talks about upgrading NPM in Visual Studio 2015. I followed the steps therein, and my build started working again.
That’s some fun code ninjary there, if I do say so myself. Nothing like venturing off the beaten path and surprising yourself with a solution!
Posting in hopes that it will help someone else…