6
votes

Détermination des autorisations d'écriture dans le dossier d'application

J'ai une application C # et je dois jeter une certaine sortie dans un fichier journal pendant le fonctionnement. Je veux donner à l'utilisateur l'option d'où localiser le fichier journal, mais par la demande du client, il doit être par défaut à l'emplacement de l'application actuel, qui est normalement / program fichiers /.

Lorsque je déploie ma candidature sur une machine Win7 / Vista, l'application n'écrit pas le fichier journal, à moins que je ne puisse exécuter le programme en tant qu'administrateur. Dans le même temps, il semble manipuler silencieusement le cas où il ne peut pas écrire le fichier, car je gère actuellement toutes les exceptions étant lancées pendant la création de fichiers et le processus d'écriture.

J'essaie actuellement de détecter le manque d'autorisation d'écriture par les deux:

a) Création d'un objet DirectorySecurity en appelant "Directory.getaCessControl ()" et

B) Vérification des privilèges de sécurité avec la méthode "SecurityManager.isgranced (Autorisations)",

Mais A ne jette pas une exception quand je m'attends à ce que ce soit, et b retourne vrai à chaque fois.

J'ai vu de nombreux postes liés à ce sujet, mais ils donnent tous la solution d'écrire juste à l'application.UserAppDaTrafolder ou à une variation de celui-ci. Mon client a spécifiquement demandé à la défaillance du chemin de candidature en cours. J'ai donc besoin de trouver au moins un moyen de les avertir gracieusement lors de la rédaction du fichier journal allant en panne silencieusement.

Remarque: mon code actuel fonctionne sur Windows XP (car il n'y a pas d'UAC, je suppose). Fondamentalement, tout ce que j'ai besoin de savoir, c'est pourquoi tous mes appels me disent que la rédaction du fichier va bien, lorsque le fichier n'est jamais créé du tout à moins que je ne fonctionne pas en tant qu'administrateur.

Merci!


2 commentaires

Si vous attendez que votre demande soit installée dans les fichiers de programme, vous devriez vraiment essayer de persuader votre client que c'est une très mauvaise idée d'écrire des fichiers journaux là-bas. Ils appartiennent vraiment à% Appdata%. Sauf si bien sûr, vous envisagez d'exécuter votre application à partir d'un dossier ailleurs (par exemple un lecteur USB)


Désolé pour le bowvote; Je suis grosse le doigter hier et maintenant je ne peux pas le changer.


6 Réponses :


2
votes

Vous pouvez forcer le système d'exploitation à exécuter votre application comme administrateur.

<requestedExecutionLevel level="requireAdministrator" uiAccess="false" />


0 commentaires

0
votes

Le test ultime de savoir si vous avez les droits d'écrire un fichier consiste à l'ouvrir pour l'écriture. C'est à dire. xxx


1 commentaires

Le problème avec c'est que lorsque la virtualisation se passe (application non manifestée), il n'y a aucune erreur ni exception. L'écriture réussit. Cela ne se produit tout simplement pas dans les fichiers de programme, c'est tout. Mais il n'y a rien pour vous d'attraper.



0
votes

Outre la suggestion de Stefan P. d'élever l'application pour exécuter en tant qu'administrateur, vous pouvez également modifier la permission du dossier d'installation sur Installer pour ajouter le groupe d'utilisateurs à avoir un accès en écriture. Ensuite, l'application fonctionnerait également.

Déplacement de l'emplacement du fichier journal serait la meilleure option.


0 commentaires

6
votes

Windows Vista et 7 écrivent des fichiers dans le répertoire des fichiers de programme tout simplement bien.

Eh bien, pas vraiment, mais le programme pense que c'est très bien. En réalité, le fichier est écrit dans le répertoire VirtualStore actuel de l'utilisateur; c'est-à-dire dans % userprofile% \ Appdata \ local \ VirtualStore \ Program Files

Vous pouvez Inclure un fichier manifeste pour désactiver ce comportement pour votre application pour obtenir les résultats que vous attendez.


1 commentaires

Vous avez absolument raison. C'est exactement ce qui se passe. Merci pour l'aide!



2
votes

Il y a trois façons que votre application peut exécuter - élevée, délibérément non élevée (disant manifeste asinvoker ) ou accidentellement non élevé (pas de manifeste). Les applications élevées pourront écrire sur les fichiers de programme. Des applications délibérément non élevées auront accès à l'accès refusé. Les applications accidentellement non élevées ne réussiront, mais le fichier sera écrit ailleurs. Ce dernier cas est ce qui vous arrive. Il n'a pas échoué silencieusement. Vous ne savez tout simplement pas où sont les fichiers. Voir http://www.gregcons.com/kateblog/finindingfilesyoursuyouwrote.aspx pour les captures d'écran.

Par conséquent, si les utilisateurs insistent sur le répertoire actuel, vous devez ajouter un manifeste demande asinvoker . Vous aurez alors accès et ils verront le message d'erreur. Je pense qu'ils sont étranges pour vouloir cela. Demandez-leur si elles sont correctes avec un excès de clic pour les trouver: Si oui, gardez votre application à l'aide de la virtualisation (je désapprouve vraiment) en n'ayant pas de manifeste, puis de les former à cliquer sur le bouton Fichiers de compatibilité. Ma préférence: écrivez ailleurs et manifeste à asinvoker . Mon deuxième choix: Stick avec le répertoire actuel, pas de manifeste, formez-les pour trouver des fichiers virtualisés. Mon troisième choix: Stick avec le répertoire actuel, manifeste à asinvoker , utilisateurs Voir les messages d'erreur lorsque les fichiers journaux ne sont pas écrits, mais les journaux sont perdus.


0 commentaires

1
votes

Je rencontre le même problème. J'ai un fichier XML que j'écris à ... Lorsque j'installe l'application (C Sharp) et j'essaie d'exécuter l'application pour obtenir une exception en raison de la permission d'écriture. Lorsque je modifie la permission du fichier (donnez la permission de lecture aux utilisateurs), il fonctionne bien ..


0 commentaires