2008-10-10 6 views
11

Où écrivez-vous un fichier journal d'erreur, par exemple ErrorLog.txt, dans Windows? Gardez à l'esprit que le chemin doit être ouvert aux utilisateurs de base pour les autorisations d'écriture de fichiers.Où sont les meilleurs emplacements pour écrire un journal des erreurs dans Windows?

Je sais que le journal des événements est un emplacement possible pour les erreurs d'écriture, mais fonctionne-t-il pour les autorisations de niveau "utilisateur"?

EDIT: Je suis en train de cibler Windows 2003, mais je posais la question de manière à avoir une «directive générale» pour savoir où écrire les journaux d'erreurs.
En ce qui concerne le journal des événements, j'ai déjà rencontré des problèmes dans une application ASP.NET où je souhaitais me connecter au journal des événements Windows, mais des problèmes de sécurité me causaient du chagrin. (Je ne me souviens pas des problèmes que j'avais, mais je me souviens d'en avoir.)

+0

Pouvez-vous être plus précis sur le type de programme ou le type de les erreurs que vous avez l'intention de vous connecter Quelle est l'importance des erreurs en termes de long terme. (par exemple serveur web?) –

+0

Il serait utile de savoir avec quelle technologie vous développez et quelle version de l'OS que vous ciblez également. :) –

Répondre

14

Avez-vous envisagé de consigner la visionneuse d'événements à la place? Si vous voulez écrire votre propre journal, je suggère le répertoire de configuration de l'application locale des utilisateurs. Créez un répertoire de produits sous. C'est différent sur une version différente de Windows.

Sur Vista, vous ne pouvez pas placer des fichiers de ce type sous les fichiers c: \ program. Vous rencontrerez beaucoup de problèmes avec cela.

Dans .NET, vous pouvez trouver ce dossier avec ceci:

Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData) 

Et le journal des événements est assez simple à utiliser aussi:

http://msdn.microsoft.com/en-us/library/system.diagnostics.eventlog.aspx

+0

Le répertoire de configuration de l'application est un bon emplacement. –

+0

Le problème avec l'utilisation du dossier de configuration de l'application est que la plupart du temps, les fichiers journaux sont ouverts manuellement dans le bloc-notes. pour Explorer, ce qui signifie que l'utilisateur va devoir aller le chercher. –

+1

En règle générale, je fournis un mécanisme via l'interface utilisateur pour ouvrir directement le fichier journal. Et votre logiciel fonctionne toujours, alors quand vont-ils avoir besoin de regarder le journal, non? ;) –

0

% TEMP% est toujours un bon emplacement pour les journaux que je trouve.

+0

Si les journaux sont relativement sans importance à long terme, je serais d'accord Temp est la bonne chose. –

-5

Mettez-le dans le répertoire de l'application. Les utilisateurs auront besoin d'accéder au dossier pour exécuter et exécuter l'application, et vous pouvez vérifier l'accès en écriture au démarrage de l'application.

Le journal des événements est difficile à utiliser pour le dépannage, mais vous devez toujours y signaler des erreurs significatives.

EDIT - Vous devriez regarder dans les blocs MS Application pour la journalisation si vous utilisez .NET. Ils rendent vraiment la vie facile.

Jeez Karma-tueurs. La prochaine fois, je ne proposerai même pas une suggestion lorsque l'affiche met en place un post incomplet.

+0

Les journaux d'application ne doivent pas être placés dans le répertoire de l'application. Dans un environnement sécurisé, les non-administrateurs n'auront pas d'accès en écriture. –

+0

L'insertion d'un fichier journal dans le répertoire dans lequel l'application est installée est une idée * BAD * * BAD *. Je ne peux pas répéter cela assez fort. Un utilisateur sur Vista peut être en mesure d'exécuter une application, mais ils ne pourront pas (et ne devraient pas pouvoir) écrire dans le répertoire de l'application dans% PROGRAMFILES% – Rob

+0

Pas une option pour les programmes sous Vista, et une mauvaise idée dans général. Vista ne permettra pas au programme de créer des fichiers dans 'Program Files', donc si l'application est installée, la journalisation échouera de façon drastique. – workmad3

3

Personnellement, je suggère d'utiliser le journal des événements Windows, c'est génial. Si vous ne pouvez pas, puis écrire le fichier dans le répertoire ApplicationData ou le répertoire ProgramData (Application Data pour tous les utilisateurs sous Windows XP).

2

L'emplacement standard (s) sont:

C:\Documents and Settings\All Users\Application Data\MyApp 

ou

C:\Documents and Settings\%Username%\Application Data\MyApp 

(alias %UserProfile%\Application Data\MyApp) qui ne respecterait niveau utilisateur exigence d'autorisation. Il sépare également les journaux créés par différents utilisateurs.

En utilisant .NET exécution, ceux-ci peuvent être construits comme:

AppDir= 
    System.Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData) 

ou

AppDir= 
    System.Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData) 

suivi de:

MyAppDir = IO.Path.Combine(AppDir,'MyApp') 

(qui, nous l'espérons, les cartes profils Vista aussi).

+0

Ce n'est pas juste pour Vista - (préférable d'utiliser.Classe d'environnement NET, ou quelque chose qui enveloppe le bon appel dans la langue que vous utilisez) –

2

Le journal des événements Windows est définitivement la méthode à utiliser pour la consignation des erreurs. Vous n'êtes pas limité au journal "Application" car il est possible de créer une nouvelle cible de journal (par exemple, "Mon application"). Cela peut devoir être fait dans le cadre de l'installation car je ne suis pas sûr si cela nécessite des privilèges administratifs ou non. Il y a un exemple de Microsoft en C# au http://support.microsoft.com/kb/307024.

Windows 2008 a également Event Log Forwarding ce qui peut être très pratique avec les applications serveur.

+0

Créer une nouvelle "Source d'événement" (texte dans un champ) dans un journal existant nécessite des autorisations d'administrateur, donc je suppose que la création d'un nouveau Log (un fichier entièrement nouveau) nécessiterait également des droits d'administrateur. –

+0

C'était le «problème» que j'avais auparavant, les droits d'administrateur requis pour l'application Web pour créer le journal dans le journal des événements Windows. –

0

Aller contre le grain ici - cela dépend de ce que vous devez faire. Parfois, vous devez manipuler les résultats, donc log.txt est la voie à suivre. C'est simple, mutable et facile à chercher.

Prenons un exemple de Joel. Fogbugz enverra un log/dump de messages d'erreur via http à leur serveur. Vous pouvez faire de même et ne pas avoir à vous soucier des droits d'accès de l'utilisateur sur son lecteur.

5

Les fichiers texte sont parfaits pour une application serveur (vous avez dit Windows 2003). Vous devriez avoir un fichier journal séparé pour chaque application serveur, l'emplacement est vraiment une question de convention pour être d'accord avec les administrateurs. Par exemple. Pour les applications ASP.NET, je les ai souvent vues placées sur un disque distinct de l'application sous une structure de dossiers qui imite la structure du répertoire virtuel.

Pour les applications client, l'un des inconvénients des fichiers texte est qu'un utilisateur peut démarrer plusieurs copies de votre application (sauf si vous avez pris des mesures spécifiques pour empêcher cela). Vous avez donc le problème de contention si plusieurs instances tentent d'écrire dans le même fichier journal. Pour cette raison, je préférerais toujours le journal des événements Windows pour les applications client. Une mise en garde est que vous devez être un administrateur pour créer un journal des événements - cela peut être fait par exemple. par le package d'installation.

Si vous utilisez un fichier, je suggère d'utiliser le dossier Environment.SpecialFolder. locaux ApplicationData plutôt que SpecialFolder.ApplicationData comme suggéré par d'autres. LocalApplicationData se trouve sur le disque local: vous ne voulez pas que des problèmes de réseau vous empêchent de vous connecter lorsque l'utilisateur a un profil itinérant. Pour une application WinForms, utilisez Application.LocalUserAppDataPath. Dans les deux cas, je voudrais utiliser un fichier de configuration pour décider où se connecter, de sorte que vous pouvez facilement le changer. Par exemple. si vous utilisez Log4Net ou un cadre similaire, vous pouvez facilement configurer si vous souhaitez vous connecter à un fichier texte, journal des événements, les deux ou ailleurs (par exemple une base de données) sans changer votre application.

1

Je suis d'accord avec Lou sur ce point, mais je préfère le mettre en place dans un fichier de configuration comme Joe dit. Vous pouvez utiliser

valeur file = "$ {} APPDATA /Test/log-file.txt"

("Test" pourrait être tout ce que vous voulez, ou le retrait définitif) dans le fichier de configuration, ce qui provoque la le fichier journal à écrire dans "/ Documents and Settings/LoginUser/application données/test" sur Windows XP et «/Users/LoginUser/AppData/Roaming/test sur Windows Vista.

Je suis juste ce que j'ajoutais viens de passer beaucoup trop de temps à trouver comment faire ce travail sur Windows Vista ...

Cela fonctionne comme-est avec des applications Windows. Pour utiliser l'enregistrement dans les applications web, je trouve l'entrée de blog de Phil Haack sur ce être une grande ressource: http://haacked.com/archive/2005/03/07/ConfiguringLog4NetForWebApplications.aspx

0

Je n'aime pas personnellement d'utiliser le journal des événements Windows où je suis en ce moment parce que nous n'avons pas accès aux serveurs de production, ce qui signifierait que nous aurions besoin de demander l'accès chaque fois que nous voudrions regarder les erreurs. Ce n'est pas un processus rapide, malheureusement, votre dépannage est complètement hantée en attendant quelqu'un d'autre. Je n'aime pas non plus qu'ils se perdent dans ceux d'autres applications. Bien sûr, vous pouvez trier, mais c'est juste un peu de nucance qui défile vers le bas. Ce que vous utilisez finira par être une combinaison de préférence personnelle couplée avec des limitations de l'environnement dans lequel vous travaillez. (Fichier journal, journal des événements ou base de données)

Questions connexes