Home/ Questions/Q 3491400
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T11:37:55+00:00

Due to certain configurations on my dev box I was forced to move my

  • 0

Due to certain configurations on my dev box I was forced to move my code to the “Documents and Settings” folders. Since our #?*&%$£ “beloved” perforce VCS can have problems with long file paths in specific scenarios, I mapped a drive (V:) to point to the code. This generally works now with one exception: for some reason, unit test runners integrated into VS cannot run tests anymore. I specifically tried this using TestDriven.NET and the ReSharper test runner. Both show the same strange behavior: no errors, tests are only NOT run.

0 Passed, 0 Failed, 0 Skipped

When I open the solution from C:\Documents… and run the tests using said runners, it works:

211 Passed, 0 Failed, 0 Skipped

I first suspected a 64bit issue (we are on Win7 Ultimate x64). But the test assemblies are set to “Any CPU”, both runners can handle that scenario and redirect to the appropriate NUnit executables (…as far as I can tell, correct me if I am mistaken!). Opening the test assemblies with the NUnit GUI both from C:\ and V:\ work fine.

I can only assume this has to do with the runners in VS not being able to invoke tests when the file paths refer to a mapped drive…but this sound pretty weird, so I was hoping some of you have seen this problem before and can give some advice.

To boil this down to a question:
Has anyone ever had issues with NUnit test runners in VS 2010 not executing tests, possibly due to the solution being on a mapped drive?

Win 7 Ultimate x64
VS 2010 Ultimate
NUnit 2.5.8
TestDriven.NET 3
ReSharper 5.1

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    OK, we finally found a way to get around this. While we did not really solve the issue with our mapped V: drive being a network drive, it does work fine if you create the mapped drive using the SUBST command.

    The difference here is that the V: drive was treated as a network location since I created the mapping using “map network drive” in the explorer menu (which I believe is equivalent to the NET command). This can lead to trust issues when assemblies are called between network and local drives. Some guys even got error messages during builds along the lines of

    Unhandled Exception:
    System.Security.SecurityException:
    That assembly does not allow partially
    trusted callers.

    Using SUBST our V: drive points to a local (=trusted) location, and now our tests all run as expected.

    To create a mapped drive with SUBST, do the following. This examples maps a new virtual drive “V” to the code location in the users’ (= [yourName]) folder:

    C:>subst v: C:\Users[yourName]\code

    • 0