Comme je suis pas du style à me faire ch*er, j'ai donc installé VS7 sur le serveur TSE pour pouvoir débogger sans Holmes, Watson, Dump & Dumber etc...
Et la quand je lance mon appli en mode déboggage, tout tourne parfaitement.
Mais quand je lance l'exe j'ai une fenetre de titre JIT qui me dit PID non valide !?! Quésaquo ???
Merci MrChris
Thierry Bertrand
A mon humble avis, s'il y a une différence entre le mode debug et le mode exe compilé, alors c'est que tu as une initialisation qui dans un cas s'effectue, et dans un autre non car la vitesse d'exécution et la simultaneïté ne sont pas les mêmes dans les deux cas.
Par exemple un objet n'est pas encore créé alors que tu le références dans l'exe, et en mode debug, cet objet est bien créé quand tu passes dans la séquence qui le référence et le problème n'existe plus.
Moi c'est ça que j'dirais.
Essaye de voir du coté des procédures d'initialisation des formes ou autres objets pour voir ?
"MrChris" a écrit dans le message de news: Oyr$7uW#
Bon, il y a du nouveau !!!
Comme je suis pas du style à me faire ch*er, j'ai donc installé VS7 sur le serveur TSE pour pouvoir débogger sans Holmes, Watson, Dump & Dumber etc...
Et la quand je lance mon appli en mode déboggage, tout tourne
parfaitement.
Mais quand je lance l'exe j'ai une fenetre de titre JIT qui me dit PID non valide !?! Quésaquo ???
Merci MrChris
A mon humble avis, s'il y a une différence entre le mode debug et le mode
exe compilé, alors c'est que tu as une initialisation qui dans un cas
s'effectue, et dans un autre non car la vitesse d'exécution et la
simultaneïté ne sont pas les mêmes dans les deux cas.
Par exemple un objet n'est pas encore créé alors que tu le références dans
l'exe, et en mode debug, cet objet est bien créé quand tu passes dans la
séquence qui le référence et le problème n'existe plus.
Moi c'est ça que j'dirais.
Essaye de voir du coté des procédures d'initialisation des formes ou autres
objets pour voir ?
"MrChris" <mrchris@spam.com> a écrit dans le message de news:
Oyr$7uW#EHA.3236@TK2MSFTNGP15.phx.gbl...
Bon, il y a du nouveau !!!
Comme je suis pas du style à me faire ch*er, j'ai donc installé VS7 sur le
serveur TSE
pour pouvoir débogger sans Holmes, Watson, Dump & Dumber etc...
Et la quand je lance mon appli en mode déboggage, tout tourne
parfaitement.
Mais quand je lance l'exe j'ai une fenetre de titre JIT qui me dit PID non
valide !?!
Quésaquo ???
A mon humble avis, s'il y a une différence entre le mode debug et le mode exe compilé, alors c'est que tu as une initialisation qui dans un cas s'effectue, et dans un autre non car la vitesse d'exécution et la simultaneïté ne sont pas les mêmes dans les deux cas.
Par exemple un objet n'est pas encore créé alors que tu le références dans l'exe, et en mode debug, cet objet est bien créé quand tu passes dans la séquence qui le référence et le problème n'existe plus.
Moi c'est ça que j'dirais.
Essaye de voir du coté des procédures d'initialisation des formes ou autres objets pour voir ?
"MrChris" a écrit dans le message de news: Oyr$7uW#
Bon, il y a du nouveau !!!
Comme je suis pas du style à me faire ch*er, j'ai donc installé VS7 sur le serveur TSE pour pouvoir débogger sans Holmes, Watson, Dump & Dumber etc...
Et la quand je lance mon appli en mode déboggage, tout tourne
parfaitement.
Mais quand je lance l'exe j'ai une fenetre de titre JIT qui me dit PID non valide !?! Quésaquo ???
Merci MrChris
Thierry Bertrand
Invalid PID ne serait-ce pas en français Identifiant Process invalide T'utilises des thread, donc regardes du coté du référencement d'un objet alors que le thread pourrait ne pas encore être complètement créé, ou que le process serait encore en cours de construction et pas totalement initialisé???
"MrChris" a écrit dans le message de news: Oyr$7uW# > Bon, il y a du nouveau !!! > > Comme je suis pas du style à me faire ch*er, j'ai donc installé VS7 sur
le
> serveur TSE > pour pouvoir débogger sans Holmes, Watson, Dump & Dumber etc... > > Et la quand je lance mon appli en mode déboggage, tout tourne parfaitement. > > Mais quand je lance l'exe j'ai une fenetre de titre JIT qui me dit PID
Invalid PID ne serait-ce pas en français Identifiant Process invalide
T'utilises des thread, donc regardes du coté du référencement d'un objet
alors que le thread pourrait ne pas encore être complètement créé, ou que le
process serait encore en cours de construction et pas totalement
initialisé???
"MrChris" <mrchris@spam.com> a écrit dans le message de news:
Oyr$7uW#EHA.3236@TK2MSFTNGP15.phx.gbl...
> Bon, il y a du nouveau !!!
>
> Comme je suis pas du style à me faire ch*er, j'ai donc installé VS7 sur
le
> serveur TSE
> pour pouvoir débogger sans Holmes, Watson, Dump & Dumber etc...
>
> Et la quand je lance mon appli en mode déboggage, tout tourne
parfaitement.
>
> Mais quand je lance l'exe j'ai une fenetre de titre JIT qui me dit PID
Invalid PID ne serait-ce pas en français Identifiant Process invalide T'utilises des thread, donc regardes du coté du référencement d'un objet alors que le thread pourrait ne pas encore être complètement créé, ou que le process serait encore en cours de construction et pas totalement initialisé???
"MrChris" a écrit dans le message de news: Oyr$7uW# > Bon, il y a du nouveau !!! > > Comme je suis pas du style à me faire ch*er, j'ai donc installé VS7 sur
le
> serveur TSE > pour pouvoir débogger sans Holmes, Watson, Dump & Dumber etc... > > Et la quand je lance mon appli en mode déboggage, tout tourne parfaitement. > > Mais quand je lance l'exe j'ai une fenetre de titre JIT qui me dit PID
Effectivement j'ai des threads, mais je me force à programmer en option explicit on option strict on
Et je n'ai aucun late binding dans mon code. Par contre, je lance l'application sur un volume partagé (elle est sur un autre serveur que TSE). Je vais essayer de voir si je la lance en local il me fait le même message d'erreur...
Merci pour vos aides ! MrChris
Effectivement j'ai des threads, mais je me force à programmer en
option explicit on
option strict on
Et je n'ai aucun late binding dans mon code.
Par contre, je lance l'application sur un volume partagé (elle est sur un
autre serveur que TSE).
Je vais essayer de voir si je la lance en local il me fait le même message
d'erreur...
Effectivement j'ai des threads, mais je me force à programmer en option explicit on option strict on
Et je n'ai aucun late binding dans mon code. Par contre, je lance l'application sur un volume partagé (elle est sur un autre serveur que TSE). Je vais essayer de voir si je la lance en local il me fait le même message d'erreur...
Merci pour vos aides ! MrChris
MrChris
Aaaahh ! Mon appli fonctionne parfaitement quand je la lance en local (sur le serveur TSE)... Mais pas quand je la lance à partir d'un volume partagé (depuis le serveur TSE)... Sur le volume distant, j'ai toutes les dll etc requise pour que l'appli tourne et ce volume est en accès total pour tout le monde !!!
Alors que si je lance mon appli sur le même volume partagé mais à partir de mon poste de travail ça fonctionne.
Qu'est ce qui fait qu'un serveur d'appli windows 2003 TSE m'empèche de lancer une appli sur un volume distant avec comme erreur PID invalide ??? C'est incompréhensible pour moi, je ne vois aucune raison pour que cela ne fonctionne pas.
Merci MrChris
Aaaahh !
Mon appli fonctionne parfaitement quand je la lance en local (sur le serveur
TSE)...
Mais pas quand je la lance à partir d'un volume partagé (depuis le serveur
TSE)...
Sur le volume distant, j'ai toutes les dll etc requise pour que l'appli
tourne et ce volume
est en accès total pour tout le monde !!!
Alors que si je lance mon appli sur le même volume partagé mais à partir de
mon poste de travail
ça fonctionne.
Qu'est ce qui fait qu'un serveur d'appli windows 2003 TSE m'empèche de
lancer une appli sur un volume
distant avec comme erreur PID invalide ???
C'est incompréhensible pour moi, je ne vois aucune raison pour que cela ne
fonctionne pas.
Aaaahh ! Mon appli fonctionne parfaitement quand je la lance en local (sur le serveur TSE)... Mais pas quand je la lance à partir d'un volume partagé (depuis le serveur TSE)... Sur le volume distant, j'ai toutes les dll etc requise pour que l'appli tourne et ce volume est en accès total pour tout le monde !!!
Alors que si je lance mon appli sur le même volume partagé mais à partir de mon poste de travail ça fonctionne.
Qu'est ce qui fait qu'un serveur d'appli windows 2003 TSE m'empèche de lancer une appli sur un volume distant avec comme erreur PID invalide ??? C'est incompréhensible pour moi, je ne vois aucune raison pour que cela ne fonctionne pas.
Merci MrChris
Thierry Bertrand
Si je comprends bien:
cas 1: Un serveur TSE contenant tout : Ok pour les clients TSE
cas 2: Un serveur contenant l'appli dans un rep partagé (droits accès tout le monde) exécuté à partir d'un poste de travail: OK
cas 3: Le même serveur que le cas 2, accédé à partir d'une session TSE lancée sur le serveur du cas N° 1 - NOK NOK NOK
Pas simple tout ça.
J'envoie ce qui me passe par la tête, tant pis pour le ridicule, on est là pour ça.
La logique veut que dans les cas 3 et 1 cela soit la même chose puisqu'il n'y a pas de problème de DLL ou autres (pas de dll 32bits anciennes qui ne seraient pas enregistrées sur le serveur TSE ??? mais enregistrées sur l'autre)
Y-a-t il un setup pour cette appli (registry pas à jour entre les deux serveurs)
Le plantage se produit dès le lancement ??? y-a-t-il moyen de faire une version qui initialiser juste l'appli sans démarrer tout pour voir (j'ignore ce que fait cette appli) et voir si c'est toujours le cas.
Problème de délai de chargement de dll dans le cas 3 qui ralentirait l'exécution d'une partie des processus élémentaires par rapport à une autre (cas d'un exécution en multi et assynchrone mais nécessitant une initialisation complète de tous les composants)
Problème de GPO ? (non ça j'y crois pas vraiment mais bon ...)
Courage ...
Si je comprends bien:
cas 1: Un serveur TSE contenant tout : Ok pour les clients TSE
cas 2: Un serveur contenant l'appli dans un rep partagé (droits accès tout
le monde) exécuté à partir d'un poste de travail: OK
cas 3: Le même serveur que le cas 2, accédé à partir d'une session TSE
lancée sur le serveur du cas N° 1 - NOK NOK NOK
Pas simple tout ça.
J'envoie ce qui me passe par la tête, tant pis pour le ridicule, on est là
pour ça.
La logique veut que dans les cas 3 et 1 cela soit la même chose puisqu'il
n'y a pas de problème de DLL ou autres (pas de dll 32bits anciennes qui ne
seraient pas enregistrées sur le serveur TSE ??? mais enregistrées sur
l'autre)
Y-a-t il un setup pour cette appli (registry pas à jour entre les deux
serveurs)
Le plantage se produit dès le lancement ??? y-a-t-il moyen de faire une
version qui initialiser juste l'appli sans démarrer tout pour voir (j'ignore
ce que fait cette appli) et voir si c'est toujours le cas.
Problème de délai de chargement de dll dans le cas 3 qui ralentirait
l'exécution d'une partie des processus élémentaires par rapport à une autre
(cas d'un exécution en multi et assynchrone mais nécessitant une
initialisation complète de tous les composants)
Problème de GPO ? (non ça j'y crois pas vraiment mais bon ...)
cas 1: Un serveur TSE contenant tout : Ok pour les clients TSE
cas 2: Un serveur contenant l'appli dans un rep partagé (droits accès tout le monde) exécuté à partir d'un poste de travail: OK
cas 3: Le même serveur que le cas 2, accédé à partir d'une session TSE lancée sur le serveur du cas N° 1 - NOK NOK NOK
Pas simple tout ça.
J'envoie ce qui me passe par la tête, tant pis pour le ridicule, on est là pour ça.
La logique veut que dans les cas 3 et 1 cela soit la même chose puisqu'il n'y a pas de problème de DLL ou autres (pas de dll 32bits anciennes qui ne seraient pas enregistrées sur le serveur TSE ??? mais enregistrées sur l'autre)
Y-a-t il un setup pour cette appli (registry pas à jour entre les deux serveurs)
Le plantage se produit dès le lancement ??? y-a-t-il moyen de faire une version qui initialiser juste l'appli sans démarrer tout pour voir (j'ignore ce que fait cette appli) et voir si c'est toujours le cas.
Problème de délai de chargement de dll dans le cas 3 qui ralentirait l'exécution d'une partie des processus élémentaires par rapport à une autre (cas d'un exécution en multi et assynchrone mais nécessitant une initialisation complète de tous les composants)
Problème de GPO ? (non ça j'y crois pas vraiment mais bon ...)
Courage ...
Paul Bacelar
"Thierry Bertrand" <bertrand.thierry(nospam)@(nospam)numericable.fr> wrote in message news:#vmubMW#
Putain,
deux jours pour en arriver là ... c'est fort!
C'est un investissement sur le long terme. Il me semble inconcevable qu'un développeur Windows ne sache pas configurer une machine pour générer des dumps.
alors comme il y a des chances que ce ne soit suffisant pour répondre complètement à la question, je vais essayer de t'aider Mr Chris
J'ai donné une piste, n'oubliez pas que nous sommes bénévoles et que notre temps est compté.
et après, une fois que j'ai lancé DrWatson, je fais quoi ?
Il suit la piste pour avoir des infos sur la génération de dump.
Si j'exécute, au plantage, ce bon docteur va me demander si je veux un
dump
??? c'est bien ça?
Oui.
Et le dump, stocké où ? dans un fichier banal ? comment je le récupère
(car
je ne connais pas ce vieux DrWatson), comment je le visualise ?
Vous le lancez et vous répondez à ses questions, comme l'endroit où stocker le dump. Vous n'avez même pas essayez de lancer l'exe.
Et puis ensuite, comme je ne sais pas fatalement par coeur l'interne de windows, je l'analyse comment ???
WinDBG est un outil des plus précieux pour tous développeur Windows un peu sérieux. VS.NET avec ces dernières moutures saurait lire les dumps (pas encore essayé, je me contente de WinDBG). Donc RTFM ;-)
Où je trouve la cause, la CAUSE.
Si vous avez les PDB, vous aurez la ligne de l'erreur affichée dans WinDBG et accès aux valeurs des variables.
Monsieur veut 100 balles et un Mars en plus d'une paire de LUNETTE.
Ha bon, j'envoie le tout à redmond ???
Je suis sur Paris, c'est plus près.
Bill, mon bon Billou, tu me reçois ???
Non, moi c'est Paul.
combien? cinq sur cinq ? Super !
Quoi, c'est 5 mille dollards que tu dis ? 5000 que je te dois ? j'comprends plus.
Pour 600 Euros, je te fais une formation sur WinDBG d'une journée ;-).
Bon c'est décidé, j'achète un Mac au lieu d'un Bill ...
Quand tu aura une bombe à l'écran, tu pourra toujours cherchez où est le fichier de dump, à moins d'avoir MacOSX et là, dbg c'est autre chose que WinDBG (en bien pire).
;-)))) - juste un peu pour rigoler...
"Paul Bacelar" a écrit dans le message de news: #v4KBGD# > Trouver DrWatson sur votre TSE. > -- > Paul Bacelar > > "MrChris" wrote in message > news:OGWs5S$ > > Ok, je m'apelle... > > Et après !!! > > Bon, ok je vais chercher tout seul ! > > > > MDR ! > > > > Chris. > > > > > >
-- Paul Bacelar
"Thierry Bertrand" <bertrand.thierry(nospam)@(nospam)numericable.fr> wrote
in message news:#vmubMW#EHA.2680@TK2MSFTNGP09.phx.gbl...
Putain,
deux jours pour en arriver là ...
c'est fort!
C'est un investissement sur le long terme. Il me semble inconcevable qu'un
développeur Windows ne sache pas configurer une machine pour générer des
dumps.
alors comme il y a des chances que ce ne soit suffisant pour répondre
complètement à la question, je vais essayer de t'aider Mr Chris
J'ai donné une piste, n'oubliez pas que nous sommes bénévoles et que notre
temps est compté.
et après, une fois que j'ai lancé DrWatson, je fais quoi ?
Il suit la piste pour avoir des infos sur la génération de dump.
Si j'exécute, au plantage, ce bon docteur va me demander si je veux un
dump
???
c'est bien ça?
Oui.
Et le dump, stocké où ? dans un fichier banal ? comment je le récupère
(car
je ne connais pas ce vieux DrWatson), comment je le visualise ?
Vous le lancez et vous répondez à ses questions, comme l'endroit où stocker
le dump. Vous n'avez même pas essayez de lancer l'exe.
Et puis ensuite, comme je ne sais pas fatalement par coeur l'interne de
windows, je l'analyse comment ???
WinDBG est un outil des plus précieux pour tous développeur Windows un peu
sérieux. VS.NET avec ces dernières moutures saurait lire les dumps (pas
encore essayé, je me contente de WinDBG). Donc RTFM ;-)
Où je trouve la cause, la CAUSE.
Si vous avez les PDB, vous aurez la ligne de l'erreur affichée dans WinDBG
et accès aux valeurs des variables.
Monsieur veut 100 balles et un Mars en plus d'une paire de LUNETTE.
Ha bon, j'envoie le tout à redmond ???
Je suis sur Paris, c'est plus près.
Bill, mon bon Billou, tu me reçois ???
Non, moi c'est Paul.
combien? cinq sur cinq ? Super !
Quoi, c'est 5 mille dollards que tu dis ?
5000 que je te dois ?
j'comprends plus.
Pour 600 Euros, je te fais une formation sur WinDBG d'une journée ;-).
Bon c'est décidé, j'achète un Mac au lieu d'un Bill ...
Quand tu aura une bombe à l'écran, tu pourra toujours cherchez où est le
fichier de dump, à moins d'avoir MacOSX et là, dbg c'est autre chose que
WinDBG (en bien pire).
;-)))) - juste un peu pour rigoler...
"Paul Bacelar" <paul.bacelar@PASDESPAMlaposte.net> a écrit dans le message
de news: #v4KBGD#EHA.2804@TK2MSFTNGP15.phx.gbl...
> Trouver DrWatson sur votre TSE.
> --
> Paul Bacelar
>
> "MrChris" <mrchris@spam.com> wrote in message
> news:OGWs5S$9EHA.1452@TK2MSFTNGP11.phx.gbl...
> > Ok, je m'apelle...
> > Et après !!!
> > Bon, ok je vais chercher tout seul !
> >
> > MDR !
> >
> > Chris.
> >
> >
>
>
"Thierry Bertrand" <bertrand.thierry(nospam)@(nospam)numericable.fr> wrote in message news:#vmubMW#
Putain,
deux jours pour en arriver là ... c'est fort!
C'est un investissement sur le long terme. Il me semble inconcevable qu'un développeur Windows ne sache pas configurer une machine pour générer des dumps.
alors comme il y a des chances que ce ne soit suffisant pour répondre complètement à la question, je vais essayer de t'aider Mr Chris
J'ai donné une piste, n'oubliez pas que nous sommes bénévoles et que notre temps est compté.
et après, une fois que j'ai lancé DrWatson, je fais quoi ?
Il suit la piste pour avoir des infos sur la génération de dump.
Si j'exécute, au plantage, ce bon docteur va me demander si je veux un
dump
??? c'est bien ça?
Oui.
Et le dump, stocké où ? dans un fichier banal ? comment je le récupère
(car
je ne connais pas ce vieux DrWatson), comment je le visualise ?
Vous le lancez et vous répondez à ses questions, comme l'endroit où stocker le dump. Vous n'avez même pas essayez de lancer l'exe.
Et puis ensuite, comme je ne sais pas fatalement par coeur l'interne de windows, je l'analyse comment ???
WinDBG est un outil des plus précieux pour tous développeur Windows un peu sérieux. VS.NET avec ces dernières moutures saurait lire les dumps (pas encore essayé, je me contente de WinDBG). Donc RTFM ;-)
Où je trouve la cause, la CAUSE.
Si vous avez les PDB, vous aurez la ligne de l'erreur affichée dans WinDBG et accès aux valeurs des variables.
Monsieur veut 100 balles et un Mars en plus d'une paire de LUNETTE.
Ha bon, j'envoie le tout à redmond ???
Je suis sur Paris, c'est plus près.
Bill, mon bon Billou, tu me reçois ???
Non, moi c'est Paul.
combien? cinq sur cinq ? Super !
Quoi, c'est 5 mille dollards que tu dis ? 5000 que je te dois ? j'comprends plus.
Pour 600 Euros, je te fais une formation sur WinDBG d'une journée ;-).
Bon c'est décidé, j'achète un Mac au lieu d'un Bill ...
Quand tu aura une bombe à l'écran, tu pourra toujours cherchez où est le fichier de dump, à moins d'avoir MacOSX et là, dbg c'est autre chose que WinDBG (en bien pire).
;-)))) - juste un peu pour rigoler...
"Paul Bacelar" a écrit dans le message de news: #v4KBGD# > Trouver DrWatson sur votre TSE. > -- > Paul Bacelar > > "MrChris" wrote in message > news:OGWs5S$ > > Ok, je m'apelle... > > Et après !!! > > Bon, ok je vais chercher tout seul ! > > > > MDR ! > > > > Chris. > > > > > >
-- Paul Bacelar
Paul Bacelar
Il semble que vous oubliez une donné essentiel de .NET. Le fait que le contexte de sécurité est fonction de l'endroit où est stocké l'exécutable lancé. En mettant votre exe sur un partage, votre contexte d'exécution n'est que partiellement sécurisé, entraînant des restrictions comme un accès aux fichiers ou à la base de registre extrêmement limité. Un mauvais check dans votre application et vous plantez sur une erreur qui découle de la première ou qui est effectué par le traitement de la première erreur. Traitement qui vraisemblablement n'a pas été conçus dans un contexte sécuritaire dégradé.
-- Paul Bacelar
"Thierry Bertrand" <bertrand.thierry(nospam)@(nospam)numericable.fr> wrote in message news:uajEdGZ#
Si je comprends bien:
cas 1: Un serveur TSE contenant tout : Ok pour les clients TSE
cas 2: Un serveur contenant l'appli dans un rep partagé (droits accès tout le monde) exécuté à partir d'un poste de travail: OK
cas 3: Le même serveur que le cas 2, accédé à partir d'une session TSE lancée sur le serveur du cas N° 1 - NOK NOK NOK
Pas simple tout ça.
J'envoie ce qui me passe par la tête, tant pis pour le ridicule, on est là pour ça.
La logique veut que dans les cas 3 et 1 cela soit la même chose puisqu'il n'y a pas de problème de DLL ou autres (pas de dll 32bits anciennes qui ne seraient pas enregistrées sur le serveur TSE ??? mais enregistrées sur l'autre)
Y-a-t il un setup pour cette appli (registry pas à jour entre les deux serveurs)
Le plantage se produit dès le lancement ??? y-a-t-il moyen de faire une version qui initialiser juste l'appli sans démarrer tout pour voir
(j'ignore
ce que fait cette appli) et voir si c'est toujours le cas.
Problème de délai de chargement de dll dans le cas 3 qui ralentirait l'exécution d'une partie des processus élémentaires par rapport à une
autre
(cas d'un exécution en multi et assynchrone mais nécessitant une initialisation complète de tous les composants)
Problème de GPO ? (non ça j'y crois pas vraiment mais bon ...)
Courage ...
Il semble que vous oubliez une donné essentiel de .NET. Le fait que le
contexte de sécurité est fonction de l'endroit où est stocké l'exécutable
lancé. En mettant votre exe sur un partage, votre contexte d'exécution n'est
que partiellement sécurisé, entraînant des restrictions comme un accès aux
fichiers ou à la base de registre extrêmement limité. Un mauvais check dans
votre application et vous plantez sur une erreur qui découle de la première
ou qui est effectué par le traitement de la première erreur. Traitement qui
vraisemblablement n'a pas été conçus dans un contexte sécuritaire dégradé.
--
Paul Bacelar
"Thierry Bertrand" <bertrand.thierry(nospam)@(nospam)numericable.fr> wrote
in message news:uajEdGZ#EHA.1264@TK2MSFTNGP12.phx.gbl...
Si je comprends bien:
cas 1: Un serveur TSE contenant tout : Ok pour les clients TSE
cas 2: Un serveur contenant l'appli dans un rep partagé (droits accès tout
le monde) exécuté à partir d'un poste de travail: OK
cas 3: Le même serveur que le cas 2, accédé à partir d'une session TSE
lancée sur le serveur du cas N° 1 - NOK NOK NOK
Pas simple tout ça.
J'envoie ce qui me passe par la tête, tant pis pour le ridicule, on est là
pour ça.
La logique veut que dans les cas 3 et 1 cela soit la même chose puisqu'il
n'y a pas de problème de DLL ou autres (pas de dll 32bits anciennes qui ne
seraient pas enregistrées sur le serveur TSE ??? mais enregistrées sur
l'autre)
Y-a-t il un setup pour cette appli (registry pas à jour entre les deux
serveurs)
Le plantage se produit dès le lancement ??? y-a-t-il moyen de faire une
version qui initialiser juste l'appli sans démarrer tout pour voir
(j'ignore
ce que fait cette appli) et voir si c'est toujours le cas.
Problème de délai de chargement de dll dans le cas 3 qui ralentirait
l'exécution d'une partie des processus élémentaires par rapport à une
autre
(cas d'un exécution en multi et assynchrone mais nécessitant une
initialisation complète de tous les composants)
Problème de GPO ? (non ça j'y crois pas vraiment mais bon ...)
Il semble que vous oubliez une donné essentiel de .NET. Le fait que le contexte de sécurité est fonction de l'endroit où est stocké l'exécutable lancé. En mettant votre exe sur un partage, votre contexte d'exécution n'est que partiellement sécurisé, entraînant des restrictions comme un accès aux fichiers ou à la base de registre extrêmement limité. Un mauvais check dans votre application et vous plantez sur une erreur qui découle de la première ou qui est effectué par le traitement de la première erreur. Traitement qui vraisemblablement n'a pas été conçus dans un contexte sécuritaire dégradé.
-- Paul Bacelar
"Thierry Bertrand" <bertrand.thierry(nospam)@(nospam)numericable.fr> wrote in message news:uajEdGZ#
Si je comprends bien:
cas 1: Un serveur TSE contenant tout : Ok pour les clients TSE
cas 2: Un serveur contenant l'appli dans un rep partagé (droits accès tout le monde) exécuté à partir d'un poste de travail: OK
cas 3: Le même serveur que le cas 2, accédé à partir d'une session TSE lancée sur le serveur du cas N° 1 - NOK NOK NOK
Pas simple tout ça.
J'envoie ce qui me passe par la tête, tant pis pour le ridicule, on est là pour ça.
La logique veut que dans les cas 3 et 1 cela soit la même chose puisqu'il n'y a pas de problème de DLL ou autres (pas de dll 32bits anciennes qui ne seraient pas enregistrées sur le serveur TSE ??? mais enregistrées sur l'autre)
Y-a-t il un setup pour cette appli (registry pas à jour entre les deux serveurs)
Le plantage se produit dès le lancement ??? y-a-t-il moyen de faire une version qui initialiser juste l'appli sans démarrer tout pour voir
(j'ignore
ce que fait cette appli) et voir si c'est toujours le cas.
Problème de délai de chargement de dll dans le cas 3 qui ralentirait l'exécution d'une partie des processus élémentaires par rapport à une
autre
(cas d'un exécution en multi et assynchrone mais nécessitant une initialisation complète de tous les composants)
Problème de GPO ? (non ça j'y crois pas vraiment mais bon ...)
