VS 2010 - tests unitaires sur la cartographie d'entraînement

Question

En raison de certaines configurations sur ma boîte de dev j'ai été obligé de déplacer mon code dans les dossiers « Documents and Settings ». Depuis notre #? * &% $ £ « bien-aimée » VCS peut avoir forcément des problèmes avec de longs chemins de fichiers dans des scénarios spécifiques, j'associé une unité (V :) pour pointer vers le code. Cela fonctionne généralement maintenant à une exception près: pour une raison quelconque, les coureurs de tests unitaires intégrés dans VS ne peut pas exécuter des tests plus. J'ai essayé spécifiquement cela en utilisant TestDriven.NET et le coureur de test ReSharper. Les deux montrent le même comportement étrange: aucune erreur, les tests ne sont pas exécutés

.

  

0 adopté, 0 a échoué, 0 Skipped

Quand j'ouvre la solution de C: \ Documents ... et exécuter les tests utilisant lesdits coureurs, il fonctionne:

  

211 adopté, 0 a échoué, 0 Skipped

Je soupçonnais une question d'abord 64bit (nous sommes sur Win7 x64 Édition Intégrale). Mais les ensembles de test sont réglés sur « Any CPU », les deux coureurs peuvent gérer ce scénario et rediriger vers les executables NUnit appropriées (... pour autant que je peux dire, me corriger si je me trompe!). Ouverture des assemblages d'essai avec l'interface graphique NUnit à la fois de C: \ et V: \ excellent travail.

Je ne peux que supposer cela a à voir avec les coureurs VS ne pas pouvoir invoquer des tests lorsque les chemins de fichiers se réfèrent à un lecteur mappé ... mais ce son assez bizarre, j'espérais certains d'entre vous ont vu cette problème avant et peut donner quelques conseils.

Pour faire bouillir cela à une question:
Quelqu'un at-il jamais eu des problèmes avec les coureurs de test NUnit dans VS 2010 ne pas exécuter les tests, probablement en raison de la solution étant sur un lecteur mappé?

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

Answer 1

OK, nous avons finalement trouvé un moyen de contourner ce problème. Bien que nous ne l'avons pas vraiment résoudre le problème avec notre cartographié V: lecteur étant un lecteur réseau, il ne fonctionne bien si vous créez le lecteur en utilisant la cartographié commande subst.

La différence ici est que le V: lecteur a été traité comme un emplacement réseau depuis que je créé le mappage à l'aide dans le menu de l'explorateur « lecteur réseau carte » (qui je crois est équivalente à la la commande NET). Cela peut conduire à des problèmes de confiance lorsque les assemblées sont appelées entre le réseau et les lecteurs locaux. Certains gars ont même eu des messages d'erreur lors de constructions le long des lignes de

  

Exception non gérée:   System.Security.SecurityException:   Cet ensemble ne permet pas en partie   les appelants de confiance.

En utilisant nos V subst. Des points d'entraînement à un emplacement local (= confiance), et maintenant nos tests fonctionnent tous comme prévu

Pour créer un lecteur mappé avec subst, procédez comme suit. Cet exemple mappe un nouveau lecteur virtuel « V » à l'emplacement de code dans les utilisateurs du dossier (= [yourName]):

  

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

Answer 2

Je ne l'ai pas essayé. Mais juste une pensée. Pouvez-vous vérifier le chemin de executables pour TestDriven.Net ainsi que NUnit. Vous pourriez aussi vouloir bien vérifier la référence au projet de test. est-il relatif ou absolu?