VS 2010 - модульные тесты по сопоставлению дисков

Из-за определенных конфигураций моего ящика разработчика я был вынужден переместить свой код в папки «Документы и настройки». Так как наша #?*&%$£ "любимая" система контроля версий perforce может иметь проблемы с длинными путями к файлам в определенных сценариях, я сопоставил диск (V:), чтобы указать на код. Обычно это работает сейчас, за одним исключением: по какой-то причине средства запуска модульных тестов, интегрированные в VS, больше не могут запускать тесты. Я специально попробовал это, используя TestDriven.NET и средство запуска тестов ReSharper. Оба показывают одно и то же странное поведение: ошибок нет, тесты только НЕ запускаются.

0 пройдено, 0 не пройдено, 0 пропущено

Когда я открываю решение из C:\Documents... и запускаю тесты с помощью указанных бегунов, оно работает:

211 Пройдено, 0 Не пройдено, 0 Пропущено

Сначала я заподозрил 64-битную проблему (у нас Win7 Ultimate x64). Но тестовые сборки настроены на «Любой процессор», оба бегуна могут обрабатывать этот сценарий и перенаправлять на соответствующие исполняемые файлы NUnit (... насколько я могу судить, поправьте меня, если я ошибаюсь!). Открытие тестовых сборок с помощью графического интерфейса NUnit как из C:\, так и из V:\ работает нормально.

Я могу только предположить, что это связано с тем, что бегуны в VS не могут запускать тесты, когда пути к файлам относятся к подключенному диску... но это звучит довольно странно, поэтому я надеялся, что некоторые из вас видели эту проблему раньше и может дать совет.

Если свести это к вопросу:
Кто-нибудь сталкивался с проблемами, когда средства запуска тестов NUnit в VS 2010 не выполняли тесты, возможно, из-за того, что решение находилось на подключенном диске?

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


person galaktor    schedule 18.11.2010    source источник
comment
Что, если вы имеете дело не с MapDrives, а с внешним жестким диском? Что касается меня, я заметил, что test.dll копируется в каталог AppData Temp и запускается оттуда? Что я нахожу странным.... Вы вообще сталкивались с этим?   -  person IbrarMumtaz    schedule 26.07.2013


Ответы (2)


Я не пробовал. Но только мысль. Можете ли вы проверить путь к исполняемым файлам для TestDriven.Net, а также NUnit. Вы также можете проверить ссылку на тестовый проект. это относительно или абсолютно?

person Nilesh Gule    schedule 22.11.2010
comment
Спасибо за ответы. Я проверю это, когда у меня будет возможность, и вернусь к вам. - person galaktor; 24.11.2010
comment
Пути TD.NET или NUnit не являются проблемой. Ссылочный тестовый проект является ссылкой на проект в VS. Проблема здесь, похоже, в том, что VS использует какой-то странный рабочий каталог для вызываемых исполняемых файлов TD.NET/NUnit. Также может быть дело в разрешениях. - person galaktor; 30.11.2010

Хорошо, мы наконец нашли способ обойти это. Хотя мы на самом деле не решили проблему с нашим подключенным диском V:, который является сетевым диском, он отлично работает, если вы создаете подключенный диск с помощью SUBST.

Разница здесь в том, что диск V: рассматривался как сетевое расположение, поскольку я создал сопоставление, используя «подключить сетевой диск» в меню проводника (что, как я полагаю, эквивалентно NET). Это может привести к проблемам доверия, когда сборки вызываются между сетевыми и локальными дисками. Некоторые ребята даже получали сообщения об ошибках во время сборки в духе

Необработанное исключение: System.Security.SecurityException: эта сборка не допускает частично доверенных вызывающих объектов.

Используя SUBST, наш диск V: указывает на локальное (=доверенное) расположение, и теперь все наши тесты выполняются, как и ожидалось.

Чтобы создать подключенный диск с помощью SUBST, выполните следующие действия. В этом примере новый виртуальный диск «V» сопоставляется с расположением кода в папке пользователей (= [yourName]):

C:>subst v: C:\Users[вашеимя]\code

person galaktor    schedule 10.12.2010