2008-09-19 9 views
2

J'essaie d'écrire un test qui, dans ses installations de configuration, il sauvegarde un fichier et supprime l'original, exécute le test sans l'original présent, puis dans le démontage, restaure l'original de la sauvegarde. Le fichier se trouve dans mon dossier% ProgramFiles%. Je reçois une exception UnauthorizedAccessException sur l'instruction fileInfo.Delete(). Je n'ai aucun problème à supprimer ce fichier d'un autre projet de test sur la même machine qui ne fonctionne pas à partir de Resharper Test Runner.Pourquoi ne puis-je pas supprimer un fichier dans% ProgramFiles% à partir d'un test unitaire via le test d'unité de test de Resharper?

Je ne peux pas déplacer le fichier ailleurs - c'est ssapi.dll, une DLL installée pour Visual SourceSafe. (Oui, je fais quelque chose d'invasif dans un test d'unité.)

C'est le même utilisateur (moi) pour les deux façons - je l'ai vérifié via le Gestionnaire des tâches. Mon compte d'utilisateur est membre du groupe Administrateurs local. Quels sont les autres facteurs qui déterminent mon "Autorisation" à faire quelque chose avec un fichier? RÉSOLU: Bien qu'il ne réponde pas à ma question initiale (dont j'aimerais toujours connaître la réponse), j'ai trouvé une solution de contournement à mes fins de test, en utilisant le framewok System.Security.Permissions. Demande de FileIOPermissionAccess.Read dans le code app (non-test) qui nécessite le fichier (pour un appel Interop), et un refus pour le même dans le test de ce code qui nécessite un scénario que ce fichier n'est pas là. Cela devrait fonctionner pour l'instant (et j'apprécie avoir appris un peu plus sur l'espace de noms System.Security.Permissions)!

Répondre

0

Il est possible que ReSharper exécute son Runner de test en tant que processus séparé, et ce processus distinct n'utilise pas votre identité Windows, mais plutôt un autre avec des privilèges inférieurs.

Vous pourriez être en mesure de vérifier cette ouverture Gestionnaire des tâches et en vérifiant Afficher les processus de tous les utilisateurs.

1

Pas vraiment une solution, mais je envisagerais de régler ce problème sous un angle différent.

Vous pourriez peut-être envisager de remplacer le répertoire par% AppData% (vous devrez peut-être également effectuer cette modification pour votre application principale).

Il pourrait résoudre votre problème et vous verra bien lorsque vous passerez à Vista, car UAC pourrait vous empêcher d'utiliser le répertoire% ProgramFiles% (ou l'utilisateur de l'application).

0

Vous pouvez probablement corriger cela en donnant à votre compte utilisateur un accès complet à ce dossier.

Accédez au dossier dans Windows Explorer. Faites un clic droit sur le dossier et sélectionnez les propriétés. Sélectionnez l'onglet de sécurité, puis le bouton Modifier et ajoutez le contrôle total pour vous-même. Oui - Je suppose que c'est un problème de sécurité potentiel, mais vous devez changer les fichiers dans ce répertoire, et vous semblez savoir ce que vous faites, donc cela devrait fonctionner.

0

Vous pouvez activer l'audit du fichier et vérifier le message d'erreur dans le journal des événements. Notez que vous devez activer l'audit à deux endroits, une fois sous Stratégie de sécurité locale/Stratégies locales/Stratégie d'audit et une fois sur le fichier lui-même. Cela ne résoudrait pas le problème, mais aiderait au moins à diagnostiquer le problème.

0

Exécutez-vous Vista ou Server 2008 avec UAC activé? Si oui, cela pourrait être la cause - le processus du coureur de test peut ne pas être en mode «élevé».

Questions connexes