J'ai un service WCF hébergé IIS et j'essaie d'utiliser répertoire.exists.exists () méthode. Si l'emplacement du réseau inexistant est passé, cette méthode est suspendue. J'ai googlé pour cela et j'ai constaté que c'est "une sorte d'ok" en raison de annuaire.exists.exists () implémentation intérieure. Mais j'ai écrit une application de console simple qui fait la même chose et annuaire.exists.exists () ne se bloque jamais, retourne toujours ' false '. J'exécute l'application sous mon compte (administrateur) et la piscine IIS fonctionne sous "Service réseau".
Avez-vous des idées pourquoi? Quelle est la différence entre faire la même chose dans un service ou une application de console?
4 Réponses :
Ceci pourrait être provoqué par des trucs de contrôle de l'autorisation d'utilisateur présents dans Windows (rappelez-vous lorsque vous essayez d'accéder à un dossier que vous n'avez pas accès à Windows? Il attend un peu de temps à répondre "Vous ne pouvez pas accéder à , ... "ou quelque chose comme ça).
Quel est l'utilisateur que vous exécutez l'application? Votre ID utilisateur (selon ce que vous avez dit, vous pouvez accéder à ce dossier exécutant l'application de la console) est capable de voir ce dossier.
Alors, essayez d'exécuter l'application comme votre propre identifiant utilisateur.
En outre, cochez ce lien: https://stackoverflow.com/a/21385162/1378854
Êtes-vous sûr que l'application est exécutée en tant que service réseau? Un compte de service réseau local n'aura pas accès au réseau.
Utilisez le chemin UNC au lieu d'un lecteur réseau mappé, car le lecteur mappé est spécifique à votre compte d'utilisateur. En outre, comme Kman a souligné, assurez-vous que l'identité du pool d'applications a accès à la destination du chemin UNC.
S'il vous plaît visitez ce lien:
http://msdn.microsoft.com/en-us/library /ff649309.aspx Comment obtenir le chemin de travail d'une application WCF?
Merci.
La clé ici consiste vraiment à fonctionner sur le service réseau par rapport au compte administrateur.
Vous savez que le plus tard peut accéder à l'emplacement du réseau, mais vous n'êtes vraiment pas sûr de si la boîte antérieure.
Voici un exemple d'un cas où vous pourriez vous attendre, il n'y a pas d'accès, mais cela ne fonctionne pas vraiment: https: // serverfault .COM / A / 177150
Le fait que la machine avec le lecteur partagé ne soit pas sur un domaine est où votre problème principal est
Comment détectez-vous le suspendre? Et dans lequel Trustlevel a-t-il couru votre IIS?
@ Grumbler85 Je peux voir qu'à utiliser un débogueur et une journalisation (qui s'arrête réellement sur le point de l'appel de la méthode). Je gère le service sur IIS 7.5, je n'ai pas modifié les paramètres de niveau de confiance.
Vous pouvez essayer d'exécuter le pool d'applications pour votre service dans IIS temporairement en tant que système local - si cela fonctionne bien sous le système local, vous sauriez que c'est une autorisation liée.
Quel est le chemin actuel? Est-ce un chemin UNC ou est-ce que l'emplacement du réseau est-il mappé sur une lettre de lecteur?
Comment êtes-vous sûr que cette méthode provoque définitivement le service de suspendre le service? La documentation de cette méthode indique qu'il ne jette aucune exception, je serais donc très surpris si c'est le coupable. Vous avez allumé la journalisation WCF, car cela pourrait vous aider à piller le problème.
@Fresh Eh bien, comme je l'ai dit plus tôt, je peux voir que le service se bloque à travers le débogueur et que ma journalisation personnalisée s'arrête également à ce stade. J'ai trouvé une explication ici Stackoverflow.com/questions/8434958/... , mais la question est de savoir pourquoi le comportement est différent pour la demande de console et un service exécuté sous IIS.
@RENE Le chemin actuel est UNC.
Pouvez-vous mettre en œuvre l'appel natif sur
GetFileAttribuSExetgetlasterroret laissez-nous savoir ce que le L'issue des résultats est.Je ne pense pas que le point important est "Service VS Console App", mais plutôt "Service réseau VS Compte administrateur". Le service réseau a des autorisations restreintes par conception et ne peut probablement pas accéder à la part du réseau. Vous pouvez essayer d'utiliser une identité différente pour votre AppPool; celui qui a la permission d'accéder au réseau.