Comportement au chargement d'uneSolution sous visual studio.
3 réponses
cpeltier
Mon appli est configurée comme suit :
sous IIS :
configuration pour page défaut = default.aspx
dans web.config :
<authentication mode="Forms">
<forms loginUrl="login.aspx" timeout="20"></forms>
</authentication>
pour info Global.asax par défaut n'a pas été modifié.
Voulant tracer, j'ai créé une procédure TracerProc(Nom_Procédure,session)
que j'ai placé dans un module Util.vb.
Cette procédure écrit le nom de la procédure exécutée, le numéro de la
session et un horodatage dans un fichier texte.
J'ai placé un appel à TracerProc sous chaque Procédure de mon appli, et en
particulier dans la procédure
InitialiserSession appellée par l'événement :
Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs)
Handles MyBase.Load
de la page login.aspx
donc, pour résumer, IIS pointe sur default.aspx qui est déroutée vers
login.aspx,
lequel login.aspx fait appel à TracerProc qui enregistre l'appel dans un
fichier log.
Pour en revenir à ma question, lorsque je charge la solution sous visual
studio,j'obtiens le message d'erreur suivant :
Le débogage JIT a échoué avec l'erreur suivante : Accès refusé
Le débogage JIT a été lancé par le compte d'utilisateur 'xxxxx\Aspnet'.
Pour plus d'information, recherchez "débogage juste-àtemps,erreurs" dans
l'index de la documentation
et je constate un enregistrement dans mon fichier log :
"ACCES - InitialiserSession - le : jeudi 15 sept. 2005 - à : 22:02:57
par - xffu1ty4rchlxhfj12fjd555"
donc un début d'exécution de l'appli... sans l'avoir demandé (?!)
J'obtiens alors, normalement, l'affichage des sources de mon appli.
Un passage sous le gestionnaire des tâches montre alors que aspnet_wp.exe
occupe entre 23 et 35 Mo de mémoire,
au lieu des 3 Mo attendus et obtenus après avoir sélectionné et détruit le
process initial.
Qui peut me donner des informations sur ce comportement, m'expliquer
pourquoi et comment TracerProc est exécutée.
(Pour parfaire le tout j'ai essayé de mettre une instruction stop en tête de
tracerproc, elle n'empêche pas l'écriture en log..)
sous IIS : configuration pour page défaut = default.aspx
dans web.config : <authentication mode="Forms"> <forms loginUrl="login.aspx" timeout="20"></forms> </authentication>
pour info Global.asax par défaut n'a pas été modifié.
Voulant tracer, j'ai créé une procédure TracerProc(Nom_Procédure,session) que j'ai placé dans un module Util.vb. Cette procédure écrit le nom de la procédure exécutée, le numéro de la session et un horodatage dans un fichier texte. J'ai placé un appel à TracerProc sous chaque Procédure de mon appli, et en particulier dans la procédure InitialiserSession appellée par l'événement : Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load de la page login.aspx
donc, pour résumer, IIS pointe sur default.aspx qui est déroutée vers login.aspx, lequel login.aspx fait appel à TracerProc qui enregistre l'appel dans un fichier log.
Pour en revenir à ma question, lorsque je charge la solution sous visual studio,j'obtiens le message d'erreur suivant :
Le débogage JIT a échoué avec l'erreur suivante : Accès refusé Le débogage JIT a été lancé par le compte d'utilisateur 'xxxxxAspnet'. Pour plus d'information, recherchez "débogage juste-àtemps,erreurs" dans l'index de la documentation
et je constate un enregistrement dans mon fichier log : "ACCES - InitialiserSession - le : jeudi 15 sept. 2005 - à : 22:02:57 par - xffu1ty4rchlxhfj12fjd555"
donc un début d'exécution de l'appli... sans l'avoir demandé (?!)
J'obtiens alors, normalement, l'affichage des sources de mon appli.
Un passage sous le gestionnaire des tâches montre alors que aspnet_wp.exe occupe entre 23 et 35 Mo de mémoire, au lieu des 3 Mo attendus et obtenus après avoir sélectionné et détruit le process initial.
Qui peut me donner des informations sur ce comportement, m'expliquer pourquoi et comment TracerProc est exécutée.
(Pour parfaire le tout j'ai essayé de mettre une instruction stop en tête de tracerproc, elle n'empêche pas l'écriture en log..)
Ca ne repond pas vraiment a ton pb
mais pourquoi n'utilises-tu pas les class de trace
du framwork pur faire cela?
sous IIS :
configuration pour page défaut = default.aspx
dans web.config :
<authentication mode="Forms">
<forms loginUrl="login.aspx" timeout="20"></forms>
</authentication>
pour info Global.asax par défaut n'a pas été modifié.
Voulant tracer, j'ai créé une procédure TracerProc(Nom_Procédure,session)
que j'ai placé dans un module Util.vb.
Cette procédure écrit le nom de la procédure exécutée, le numéro de la
session et un horodatage dans un fichier texte.
J'ai placé un appel à TracerProc sous chaque Procédure de mon appli, et en
particulier dans la procédure
InitialiserSession appellée par l'événement :
Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs)
Handles MyBase.Load
de la page login.aspx
donc, pour résumer, IIS pointe sur default.aspx qui est déroutée vers
login.aspx,
lequel login.aspx fait appel à TracerProc qui enregistre l'appel dans un
fichier log.
Pour en revenir à ma question, lorsque je charge la solution sous visual
studio,j'obtiens le message d'erreur suivant :
Le débogage JIT a échoué avec l'erreur suivante : Accès refusé
Le débogage JIT a été lancé par le compte d'utilisateur 'xxxxxAspnet'.
Pour plus d'information, recherchez "débogage juste-àtemps,erreurs" dans
l'index de la documentation
et je constate un enregistrement dans mon fichier log :
"ACCES - InitialiserSession - le : jeudi 15 sept. 2005 - à : 22:02:57
par - xffu1ty4rchlxhfj12fjd555"
donc un début d'exécution de l'appli... sans l'avoir demandé (?!)
J'obtiens alors, normalement, l'affichage des sources de mon appli.
Un passage sous le gestionnaire des tâches montre alors que aspnet_wp.exe
occupe entre 23 et 35 Mo de mémoire,
au lieu des 3 Mo attendus et obtenus après avoir sélectionné et détruit le
process initial.
Qui peut me donner des informations sur ce comportement, m'expliquer
pourquoi et comment TracerProc est exécutée.
(Pour parfaire le tout j'ai essayé de mettre une instruction stop en tête de
tracerproc, elle n'empêche pas l'écriture en log..)
sous IIS : configuration pour page défaut = default.aspx
dans web.config : <authentication mode="Forms"> <forms loginUrl="login.aspx" timeout="20"></forms> </authentication>
pour info Global.asax par défaut n'a pas été modifié.
Voulant tracer, j'ai créé une procédure TracerProc(Nom_Procédure,session) que j'ai placé dans un module Util.vb. Cette procédure écrit le nom de la procédure exécutée, le numéro de la session et un horodatage dans un fichier texte. J'ai placé un appel à TracerProc sous chaque Procédure de mon appli, et en particulier dans la procédure InitialiserSession appellée par l'événement : Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load de la page login.aspx
donc, pour résumer, IIS pointe sur default.aspx qui est déroutée vers login.aspx, lequel login.aspx fait appel à TracerProc qui enregistre l'appel dans un fichier log.
Pour en revenir à ma question, lorsque je charge la solution sous visual studio,j'obtiens le message d'erreur suivant :
Le débogage JIT a échoué avec l'erreur suivante : Accès refusé Le débogage JIT a été lancé par le compte d'utilisateur 'xxxxxAspnet'. Pour plus d'information, recherchez "débogage juste-àtemps,erreurs" dans l'index de la documentation
et je constate un enregistrement dans mon fichier log : "ACCES - InitialiserSession - le : jeudi 15 sept. 2005 - à : 22:02:57 par - xffu1ty4rchlxhfj12fjd555"
donc un début d'exécution de l'appli... sans l'avoir demandé (?!)
J'obtiens alors, normalement, l'affichage des sources de mon appli.
Un passage sous le gestionnaire des tâches montre alors que aspnet_wp.exe occupe entre 23 et 35 Mo de mémoire, au lieu des 3 Mo attendus et obtenus après avoir sélectionné et détruit le process initial.
Qui peut me donner des informations sur ce comportement, m'expliquer pourquoi et comment TracerProc est exécutée.
(Pour parfaire le tout j'ai essayé de mettre une instruction stop en tête de tracerproc, elle n'empêche pas l'écriture en log..)
cpeltier
Bonjour Franck,
Tout simplement parceque je suis en période de test et que je ne filtre que certaines infos... et :-) que je ne suis pas familier avec les infos fournies par trace Mais effectivement celà n'explique pas pourquoi mon appli démarre toute seule lorsque je l'ouvre sous VS ... Penses tu que les classes trace pourraient m'aider ??
"Franck" a écrit :
Ca ne repond pas vraiment a ton pb mais pourquoi n'utilises-tu pas les class de trace du framwork pur faire cela?
cpeltier wrote: > Mon appli est configurée comme suit : > > sous IIS : > configuration pour page défaut = default.aspx > > dans web.config : > <authentication mode="Forms"> > <forms loginUrl="login.aspx" timeout="20"></forms> > </authentication> > > pour info Global.asax par défaut n'a pas été modifié. > > Voulant tracer, j'ai créé une procédure TracerProc(Nom_Procédure,session) > que j'ai placé dans un module Util.vb. > Cette procédure écrit le nom de la procédure exécutée, le numéro de la > session et un horodatage dans un fichier texte. > J'ai placé un appel à TracerProc sous chaque Procédure de mon appli, et en > particulier dans la procédure > InitialiserSession appellée par l'événement : > Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) > Handles MyBase.Load > de la page login.aspx > > donc, pour résumer, IIS pointe sur default.aspx qui est déroutée vers > login.aspx, > lequel login.aspx fait appel à TracerProc qui enregistre l'appel dans un > fichier log. > > Pour en revenir à ma question, lorsque je charge la solution sous visual > studio,j'obtiens le message d'erreur suivant : > > Le débogage JIT a échoué avec l'erreur suivante : Accès refusé > Le débogage JIT a été lancé par le compte d'utilisateur 'xxxxxAspnet'. > Pour plus d'information, recherchez "débogage juste-àtemps,erreurs" dans > l'index de la documentation > > et je constate un enregistrement dans mon fichier log : > "ACCES - InitialiserSession - le : jeudi 15 sept. 2005 - à : 22:02:57 > par - xffu1ty4rchlxhfj12fjd555" > > donc un début d'exécution de l'appli... sans l'avoir demandé (?!) > > J'obtiens alors, normalement, l'affichage des sources de mon appli. > > Un passage sous le gestionnaire des tâches montre alors que aspnet_wp.exe > occupe entre 23 et 35 Mo de mémoire, > au lieu des 3 Mo attendus et obtenus après avoir sélectionné et détruit le > process initial. > > Qui peut me donner des informations sur ce comportement, m'expliquer > pourquoi et comment TracerProc est exécutée. > > (Pour parfaire le tout j'ai essayé de mettre une instruction stop en tête de > tracerproc, elle n'empêche pas l'écriture en log..) > >
Bonjour Franck,
Tout simplement parceque je suis en période de test et que je ne filtre que
certaines infos... et :-) que je ne suis pas familier avec les infos fournies
par trace
Mais effectivement celà n'explique pas pourquoi mon appli démarre toute
seule lorsque je l'ouvre sous VS ...
Penses tu que les classes trace pourraient m'aider ??
"Franck" a écrit :
Ca ne repond pas vraiment a ton pb
mais pourquoi n'utilises-tu pas les class de trace
du framwork pur faire cela?
cpeltier wrote:
> Mon appli est configurée comme suit :
>
> sous IIS :
> configuration pour page défaut = default.aspx
>
> dans web.config :
> <authentication mode="Forms">
> <forms loginUrl="login.aspx" timeout="20"></forms>
> </authentication>
>
> pour info Global.asax par défaut n'a pas été modifié.
>
> Voulant tracer, j'ai créé une procédure TracerProc(Nom_Procédure,session)
> que j'ai placé dans un module Util.vb.
> Cette procédure écrit le nom de la procédure exécutée, le numéro de la
> session et un horodatage dans un fichier texte.
> J'ai placé un appel à TracerProc sous chaque Procédure de mon appli, et en
> particulier dans la procédure
> InitialiserSession appellée par l'événement :
> Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs)
> Handles MyBase.Load
> de la page login.aspx
>
> donc, pour résumer, IIS pointe sur default.aspx qui est déroutée vers
> login.aspx,
> lequel login.aspx fait appel à TracerProc qui enregistre l'appel dans un
> fichier log.
>
> Pour en revenir à ma question, lorsque je charge la solution sous visual
> studio,j'obtiens le message d'erreur suivant :
>
> Le débogage JIT a échoué avec l'erreur suivante : Accès refusé
> Le débogage JIT a été lancé par le compte d'utilisateur 'xxxxxAspnet'.
> Pour plus d'information, recherchez "débogage juste-àtemps,erreurs" dans
> l'index de la documentation
>
> et je constate un enregistrement dans mon fichier log :
> "ACCES - InitialiserSession - le : jeudi 15 sept. 2005 - à : 22:02:57
> par - xffu1ty4rchlxhfj12fjd555"
>
> donc un début d'exécution de l'appli... sans l'avoir demandé (?!)
>
> J'obtiens alors, normalement, l'affichage des sources de mon appli.
>
> Un passage sous le gestionnaire des tâches montre alors que aspnet_wp.exe
> occupe entre 23 et 35 Mo de mémoire,
> au lieu des 3 Mo attendus et obtenus après avoir sélectionné et détruit le
> process initial.
>
> Qui peut me donner des informations sur ce comportement, m'expliquer
> pourquoi et comment TracerProc est exécutée.
>
> (Pour parfaire le tout j'ai essayé de mettre une instruction stop en tête de
> tracerproc, elle n'empêche pas l'écriture en log..)
>
>
Tout simplement parceque je suis en période de test et que je ne filtre que certaines infos... et :-) que je ne suis pas familier avec les infos fournies par trace Mais effectivement celà n'explique pas pourquoi mon appli démarre toute seule lorsque je l'ouvre sous VS ... Penses tu que les classes trace pourraient m'aider ??
"Franck" a écrit :
Ca ne repond pas vraiment a ton pb mais pourquoi n'utilises-tu pas les class de trace du framwork pur faire cela?
cpeltier wrote: > Mon appli est configurée comme suit : > > sous IIS : > configuration pour page défaut = default.aspx > > dans web.config : > <authentication mode="Forms"> > <forms loginUrl="login.aspx" timeout="20"></forms> > </authentication> > > pour info Global.asax par défaut n'a pas été modifié. > > Voulant tracer, j'ai créé une procédure TracerProc(Nom_Procédure,session) > que j'ai placé dans un module Util.vb. > Cette procédure écrit le nom de la procédure exécutée, le numéro de la > session et un horodatage dans un fichier texte. > J'ai placé un appel à TracerProc sous chaque Procédure de mon appli, et en > particulier dans la procédure > InitialiserSession appellée par l'événement : > Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) > Handles MyBase.Load > de la page login.aspx > > donc, pour résumer, IIS pointe sur default.aspx qui est déroutée vers > login.aspx, > lequel login.aspx fait appel à TracerProc qui enregistre l'appel dans un > fichier log. > > Pour en revenir à ma question, lorsque je charge la solution sous visual > studio,j'obtiens le message d'erreur suivant : > > Le débogage JIT a échoué avec l'erreur suivante : Accès refusé > Le débogage JIT a été lancé par le compte d'utilisateur 'xxxxxAspnet'. > Pour plus d'information, recherchez "débogage juste-àtemps,erreurs" dans > l'index de la documentation > > et je constate un enregistrement dans mon fichier log : > "ACCES - InitialiserSession - le : jeudi 15 sept. 2005 - à : 22:02:57 > par - xffu1ty4rchlxhfj12fjd555" > > donc un début d'exécution de l'appli... sans l'avoir demandé (?!) > > J'obtiens alors, normalement, l'affichage des sources de mon appli. > > Un passage sous le gestionnaire des tâches montre alors que aspnet_wp.exe > occupe entre 23 et 35 Mo de mémoire, > au lieu des 3 Mo attendus et obtenus après avoir sélectionné et détruit le > process initial. > > Qui peut me donner des informations sur ce comportement, m'expliquer > pourquoi et comment TracerProc est exécutée. > > (Pour parfaire le tout j'ai essayé de mettre une instruction stop en tête de > tracerproc, elle n'empêche pas l'écriture en log..) > >
Franck
le module Trace est assez bien fait,
par exemple, si tu ecrits: dans ton code de tracing avec cette condition;
if(Trace.IsEnabled)Trace.Warn("msg erreur");
en changeant la ligne suivante dans le web.config <trace enabled="true" requestLimit="20" pageOutput="false" traceMode="SortByTime" localOnly="true" /> pour <trace enabled="false"....../>
tu change une variable pour tout ton projet c bien pratique sur un site deployé
pour lire l'output, tu appeler la page: http://siteUrl/trace.axd
cpeltier wrote:
Bonjour Franck,
Tout simplement parceque je suis en période de test et que je ne filtre que certaines infos... et :-) que je ne suis pas familier avec les infos fournies par trace Mais effectivement celà n'explique pas pourquoi mon appli démarre toute seule lorsque je l'ouvre sous VS ... Penses tu que les classes trace pourraient m'aider ??
"Franck" a écrit :
Ca ne repond pas vraiment a ton pb mais pourquoi n'utilises-tu pas les class de trace du framwork pur faire cela?
sous IIS : configuration pour page défaut = default.aspx
dans web.config : <authentication mode="Forms"> <forms loginUrl="login.aspx" timeout="20"></forms> </authentication>
pour info Global.asax par défaut n'a pas été modifié.
Voulant tracer, j'ai créé une procédure TracerProc(Nom_Procédure,session) que j'ai placé dans un module Util.vb. Cette procédure écrit le nom de la procédure exécutée, le numéro de la session et un horodatage dans un fichier texte. J'ai placé un appel à TracerProc sous chaque Procédure de mon appli, et en particulier dans la procédure InitialiserSession appellée par l'événement : Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load de la page login.aspx
donc, pour résumer, IIS pointe sur default.aspx qui est déroutée vers login.aspx, lequel login.aspx fait appel à TracerProc qui enregistre l'appel dans un fichier log.
Pour en revenir à ma question, lorsque je charge la solution sous visual studio,j'obtiens le message d'erreur suivant :
Le débogage JIT a échoué avec l'erreur suivante : Accès refusé Le débogage JIT a été lancé par le compte d'utilisateur 'xxxxxAspnet'. Pour plus d'information, recherchez "débogage juste-àtemps,erreurs" dans l'index de la documentation
et je constate un enregistrement dans mon fichier log : "ACCES - InitialiserSession - le : jeudi 15 sept. 2005 - à : 22:02:57 par - xffu1ty4rchlxhfj12fjd555"
donc un début d'exécution de l'appli... sans l'avoir demandé (?!)
J'obtiens alors, normalement, l'affichage des sources de mon appli.
Un passage sous le gestionnaire des tâches montre alors que aspnet_wp.exe occupe entre 23 et 35 Mo de mémoire, au lieu des 3 Mo attendus et obtenus après avoir sélectionné et détruit le process initial.
Qui peut me donner des informations sur ce comportement, m'expliquer pourquoi et comment TracerProc est exécutée.
(Pour parfaire le tout j'ai essayé de mettre une instruction stop en tête de tracerproc, elle n'empêche pas l'écriture en log..)
le module Trace est assez bien fait,
par exemple, si tu ecrits:
dans ton code de tracing avec cette condition;
if(Trace.IsEnabled)Trace.Warn("msg erreur");
en changeant la ligne suivante dans le web.config
<trace enabled="true" requestLimit="20"
pageOutput="false"
traceMode="SortByTime"
localOnly="true" />
pour <trace enabled="false"....../>
tu change une variable pour tout ton projet c bien pratique
sur un site deployé
pour lire l'output, tu appeler la page:
http://siteUrl/trace.axd
cpeltier wrote:
Bonjour Franck,
Tout simplement parceque je suis en période de test et que je ne filtre que
certaines infos... et :-) que je ne suis pas familier avec les infos fournies
par trace
Mais effectivement celà n'explique pas pourquoi mon appli démarre toute
seule lorsque je l'ouvre sous VS ...
Penses tu que les classes trace pourraient m'aider ??
"Franck" a écrit :
Ca ne repond pas vraiment a ton pb
mais pourquoi n'utilises-tu pas les class de trace
du framwork pur faire cela?
sous IIS :
configuration pour page défaut = default.aspx
dans web.config :
<authentication mode="Forms">
<forms loginUrl="login.aspx" timeout="20"></forms>
</authentication>
pour info Global.asax par défaut n'a pas été modifié.
Voulant tracer, j'ai créé une procédure TracerProc(Nom_Procédure,session)
que j'ai placé dans un module Util.vb.
Cette procédure écrit le nom de la procédure exécutée, le numéro de la
session et un horodatage dans un fichier texte.
J'ai placé un appel à TracerProc sous chaque Procédure de mon appli, et en
particulier dans la procédure
InitialiserSession appellée par l'événement :
Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs)
Handles MyBase.Load
de la page login.aspx
donc, pour résumer, IIS pointe sur default.aspx qui est déroutée vers
login.aspx,
lequel login.aspx fait appel à TracerProc qui enregistre l'appel dans un
fichier log.
Pour en revenir à ma question, lorsque je charge la solution sous visual
studio,j'obtiens le message d'erreur suivant :
Le débogage JIT a échoué avec l'erreur suivante : Accès refusé
Le débogage JIT a été lancé par le compte d'utilisateur 'xxxxxAspnet'.
Pour plus d'information, recherchez "débogage juste-àtemps,erreurs" dans
l'index de la documentation
et je constate un enregistrement dans mon fichier log :
"ACCES - InitialiserSession - le : jeudi 15 sept. 2005 - à : 22:02:57
par - xffu1ty4rchlxhfj12fjd555"
donc un début d'exécution de l'appli... sans l'avoir demandé (?!)
J'obtiens alors, normalement, l'affichage des sources de mon appli.
Un passage sous le gestionnaire des tâches montre alors que aspnet_wp.exe
occupe entre 23 et 35 Mo de mémoire,
au lieu des 3 Mo attendus et obtenus après avoir sélectionné et détruit le
process initial.
Qui peut me donner des informations sur ce comportement, m'expliquer
pourquoi et comment TracerProc est exécutée.
(Pour parfaire le tout j'ai essayé de mettre une instruction stop en tête de
tracerproc, elle n'empêche pas l'écriture en log..)
par exemple, si tu ecrits: dans ton code de tracing avec cette condition;
if(Trace.IsEnabled)Trace.Warn("msg erreur");
en changeant la ligne suivante dans le web.config <trace enabled="true" requestLimit="20" pageOutput="false" traceMode="SortByTime" localOnly="true" /> pour <trace enabled="false"....../>
tu change une variable pour tout ton projet c bien pratique sur un site deployé
pour lire l'output, tu appeler la page: http://siteUrl/trace.axd
cpeltier wrote:
Bonjour Franck,
Tout simplement parceque je suis en période de test et que je ne filtre que certaines infos... et :-) que je ne suis pas familier avec les infos fournies par trace Mais effectivement celà n'explique pas pourquoi mon appli démarre toute seule lorsque je l'ouvre sous VS ... Penses tu que les classes trace pourraient m'aider ??
"Franck" a écrit :
Ca ne repond pas vraiment a ton pb mais pourquoi n'utilises-tu pas les class de trace du framwork pur faire cela?
sous IIS : configuration pour page défaut = default.aspx
dans web.config : <authentication mode="Forms"> <forms loginUrl="login.aspx" timeout="20"></forms> </authentication>
pour info Global.asax par défaut n'a pas été modifié.
Voulant tracer, j'ai créé une procédure TracerProc(Nom_Procédure,session) que j'ai placé dans un module Util.vb. Cette procédure écrit le nom de la procédure exécutée, le numéro de la session et un horodatage dans un fichier texte. J'ai placé un appel à TracerProc sous chaque Procédure de mon appli, et en particulier dans la procédure InitialiserSession appellée par l'événement : Page_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load de la page login.aspx
donc, pour résumer, IIS pointe sur default.aspx qui est déroutée vers login.aspx, lequel login.aspx fait appel à TracerProc qui enregistre l'appel dans un fichier log.
Pour en revenir à ma question, lorsque je charge la solution sous visual studio,j'obtiens le message d'erreur suivant :
Le débogage JIT a échoué avec l'erreur suivante : Accès refusé Le débogage JIT a été lancé par le compte d'utilisateur 'xxxxxAspnet'. Pour plus d'information, recherchez "débogage juste-àtemps,erreurs" dans l'index de la documentation
et je constate un enregistrement dans mon fichier log : "ACCES - InitialiserSession - le : jeudi 15 sept. 2005 - à : 22:02:57 par - xffu1ty4rchlxhfj12fjd555"
donc un début d'exécution de l'appli... sans l'avoir demandé (?!)
J'obtiens alors, normalement, l'affichage des sources de mon appli.
Un passage sous le gestionnaire des tâches montre alors que aspnet_wp.exe occupe entre 23 et 35 Mo de mémoire, au lieu des 3 Mo attendus et obtenus après avoir sélectionné et détruit le process initial.
Qui peut me donner des informations sur ce comportement, m'expliquer pourquoi et comment TracerProc est exécutée.
(Pour parfaire le tout j'ai essayé de mettre une instruction stop en tête de tracerproc, elle n'empêche pas l'écriture en log..)
