Pour résoudre un problème avec l'envoi d'e-mail via un serveur SMTP où les courriers électroniques ne sont pas envoyés, j'ai été informé d'activer la journalisation à l'aide de System.Diagnosis.textwriterTracelistener pour tracer la communication avec le serveur SMTP pour suivre n'importe quel les erreurs. J'ai ajouté ce qui suit à mon web.config sous le nœud:
<system.diagnostics>
<trace autoflush="true" />
<sources>
<source name="System.Net" >
<listeners>
<add name="MyTraceFile"/>
</listeners>
</source>
<source name="System.Net.Sockets">
<listeners>
<add name="MyTraceFile"/>
</listeners>
</source>
</sources>
<sharedListeners>
<add
name="MyTraceFile"
type="System.Diagnostics.TextWriterTraceListener"
initializeData="System.Net.trace.log" />
</sharedListeners>
<switches>
<add name="System.Net" value="Verbose" />
<add name="System.Net.Sockets" value="Verbose" />
</switches>
</system.diagnostics>
5 Réponses :
Est-ce la même construction de développement et de production? Fréquemment, la constante de compilation conditionnelle de la trace n'est pas définie en mode de libération. Ensuite, aucun traçage ne se présentera.
Oui, c'est la même chose dans le développement et la production. J'ai également vérifié en activant la traçabilité sur la même version, mais dans un environnement de production différent, et il a bien fonctionné. Merci pour la pointe Tho!
Avez-vous essayé d'utiliser moniteur de processus pour voir si le système .Net.trace.log Fichier est en cours d'écriture ou s'il y a une erreur la créant? Est-il possible qu'il soit juste d'être écrit à un endroit étrange que vous ne cherchez pas (je pense que la valeur par défaut doit être le répertoire de travail actuel du processus de travailleur ASP.NET).
Tout d'abord, je vérifierais si la trace fonctionne réellement sans rien écrire dans le système de fichiers. C'est-à-dire que j'utiliserais simplement la trace de Windows ordinaire. Afin de visualiser la sortie de trace, j'utiliserais Windows Sysinternals 'DebugView . Bien sûr, vous devriez peut-être modifier votre fichier de configuration, je ne suis pas aussi familier avec la syntaxe.
Maintenant, si tout fonctionne bien pour les deux environnements (développement et production), de sorte que vous puissiez visualiser les messages de trace dans la visualiseur, le problème est davantage axé sur le système de fichiers et le logement du journal.
Où pensez-vous que votre fichier journal est enregistré? Peut-être que c'est un endroit différent en ce qui concerne l'environnement de production. Je pense que sur Windows Server 2003, vous devez rechercher votre fichier quelque part sous Windir, et non dans le ou les dossiers de l'application Web.
Lorsqu'il s'agit de déboguer de tels problèmes, j'aurais intensifier le compte IIS à l'administrateur local / domaine juste pour voir si le problème est résolu ou non. Si c'est résolu, il y a une question d'autorisations ici.
bonne chance!
Je commencerais par mettre un chemin complètement qualifié dans l'attribut Initializedata: Si nécessaire, vérifiez que votre application a accès à ce chemin en ajoutant une page de test qui crée un fichier Dans le même répertoire. Lorsque vous utilisez un chemin relatif comme dans votre configuration actuelle, je pense qu'il sera relatif au répertoire racine de l'application lorsqu'il est exécuté sous IIS. Mais lors de la course sous Cassini sur une machine de développement, ce ne sera pas le cas - IIRC il sera relatif à% Windir% \ System32, mais je ne voudrais pas compter sur cela.
Juste pour les archives, il semble que vous n'ayez pas tort et que la mise en œuvre de Microsoft vérifiera si le chemin fourni dans l'initialiséeata est relatif ou non. Nicholas.piasecki.name/Blog / 2009/03 / ...
@Ocar - Blog intéressant soulignant que certains ingénieurs Microsoft avaient une mauvaise journée. Mais la solution "Mungefilename" proposée pourrait être remplacée par la "path.combine" plus simple (appdomain.currentDomaine.baseDirectory, nom de fichier) ". La méthode path.combine est suffisamment intelligente pour gérer le cas où son deuxième argument est un chemin absolu seul.
Mon problème était que la constante de trace n'était pas définie dans un projet dépendant, alors même s'il était fixé dans le projet principal, il ne se connaîtrait toujours pas. Une fois que j'ai ajouté la trace constante au projet dépendant, cela a fonctionné comme prévu.