En runtime, j'ai un client (écrit en javascript) qui invoque des fonctions
exposées par un webservice. Ce dernier écrit en C# dialogue avec une
application serveur écrite en VB6 (mon serveur est un ActiveX Exe). Le tout
fonctionne parfaitement.
Mon problème apparait, lorsque j'essaie de debuger mon ActiveX Exe.
Lorsque j'ouvre mon projet VB et que je le démarre en mode debug pour faire
du "Step by step", mon webservice ne parvient plus à s'y connecter. Le
client ne peut donc pas interagir avec l'application serveur car le
webservice qui sert d'intermédiaire ne parvient pas à dialoguer avec le
serveur.
Y'aurait-il quelqu'un qui aurait déjà expérimenter cela et qui a trouvé une
solution ?
D'avance merci.
En runtime, j'ai un client (écrit en javascript) qui invoque des fonctions
exposées par un webservice. Ce dernier écrit en C# dialogue avec une
application serveur écrite en VB6 (mon serveur est un ActiveX Exe). Le tout
fonctionne parfaitement.
Mon problème apparait, lorsque j'essaie de debuger mon ActiveX Exe.
Lorsque j'ouvre mon projet VB et que je le démarre en mode debug pour faire
du "Step by step", mon webservice ne parvient plus à s'y connecter. Le
client ne peut donc pas interagir avec l'application serveur car le
webservice qui sert d'intermédiaire ne parvient pas à dialoguer avec le
serveur.
Y'aurait-il quelqu'un qui aurait déjà expérimenter cela et qui a trouvé une
solution ?
D'avance merci.
En runtime, j'ai un client (écrit en javascript) qui invoque des fonctions
exposées par un webservice. Ce dernier écrit en C# dialogue avec une
application serveur écrite en VB6 (mon serveur est un ActiveX Exe). Le tout
fonctionne parfaitement.
Mon problème apparait, lorsque j'essaie de debuger mon ActiveX Exe.
Lorsque j'ouvre mon projet VB et que je le démarre en mode debug pour faire
du "Step by step", mon webservice ne parvient plus à s'y connecter. Le
client ne peut donc pas interagir avec l'application serveur car le
webservice qui sert d'intermédiaire ne parvient pas à dialoguer avec le
serveur.
Y'aurait-il quelqu'un qui aurait déjà expérimenter cela et qui a trouvé une
solution ?
D'avance merci.
Bonjour,
je ne sais pas si cela va t'aider mais j'ai déjà rencontré ce type de
problèmes sans trop savoir comment les résoudre ...
Ce qui se passe, c'est que l'éxecution en mode debug n'exécute pas du tout
ton programme de la même manière. En particulier, tout ce qui appelle le
système s'exécute de manière très différente. Quelques exemples de
problèmes
rencontrés :
- quand tu appelles des librairies externes, il ne va pas forcement
rechercher la même et dans le même ordre (donc si elles réagissent
différement, tu plantes sans savoir pourquoi)
- certains codes d'erreur ne sont pas les mêmes, voire certaines erreurs
ne
sont pas soulevées en mode debug
- certains appels système ne sont pas exécutés pareil (en particulier
l'appel msgbox!).
La seule solution que j'ai trouvé est de compiler et tester ! En plus, il
faut supprimer (sauf impossibilité) tous les "On Error Resume Next" pour
pouvoir identifier l'endroit exact ou tu as des problèmes ...
"Geofrey van Hecke" a écrit :En runtime, j'ai un client (écrit en javascript) qui invoque des
fonctions
exposées par un webservice. Ce dernier écrit en C# dialogue avec une
application serveur écrite en VB6 (mon serveur est un ActiveX Exe). Le
tout
fonctionne parfaitement.
Mon problème apparait, lorsque j'essaie de debuger mon ActiveX Exe.
Lorsque j'ouvre mon projet VB et que je le démarre en mode debug pour
faire
du "Step by step", mon webservice ne parvient plus à s'y connecter. Le
client ne peut donc pas interagir avec l'application serveur car le
webservice qui sert d'intermédiaire ne parvient pas à dialoguer avec le
serveur.
Y'aurait-il quelqu'un qui aurait déjà expérimenter cela et qui a trouvé
une
solution ?
D'avance merci.
Bonjour,
je ne sais pas si cela va t'aider mais j'ai déjà rencontré ce type de
problèmes sans trop savoir comment les résoudre ...
Ce qui se passe, c'est que l'éxecution en mode debug n'exécute pas du tout
ton programme de la même manière. En particulier, tout ce qui appelle le
système s'exécute de manière très différente. Quelques exemples de
problèmes
rencontrés :
- quand tu appelles des librairies externes, il ne va pas forcement
rechercher la même et dans le même ordre (donc si elles réagissent
différement, tu plantes sans savoir pourquoi)
- certains codes d'erreur ne sont pas les mêmes, voire certaines erreurs
ne
sont pas soulevées en mode debug
- certains appels système ne sont pas exécutés pareil (en particulier
l'appel msgbox!).
La seule solution que j'ai trouvé est de compiler et tester ! En plus, il
faut supprimer (sauf impossibilité) tous les "On Error Resume Next" pour
pouvoir identifier l'endroit exact ou tu as des problèmes ...
"Geofrey van Hecke" a écrit :
En runtime, j'ai un client (écrit en javascript) qui invoque des
fonctions
exposées par un webservice. Ce dernier écrit en C# dialogue avec une
application serveur écrite en VB6 (mon serveur est un ActiveX Exe). Le
tout
fonctionne parfaitement.
Mon problème apparait, lorsque j'essaie de debuger mon ActiveX Exe.
Lorsque j'ouvre mon projet VB et que je le démarre en mode debug pour
faire
du "Step by step", mon webservice ne parvient plus à s'y connecter. Le
client ne peut donc pas interagir avec l'application serveur car le
webservice qui sert d'intermédiaire ne parvient pas à dialoguer avec le
serveur.
Y'aurait-il quelqu'un qui aurait déjà expérimenter cela et qui a trouvé
une
solution ?
D'avance merci.
Bonjour,
je ne sais pas si cela va t'aider mais j'ai déjà rencontré ce type de
problèmes sans trop savoir comment les résoudre ...
Ce qui se passe, c'est que l'éxecution en mode debug n'exécute pas du tout
ton programme de la même manière. En particulier, tout ce qui appelle le
système s'exécute de manière très différente. Quelques exemples de
problèmes
rencontrés :
- quand tu appelles des librairies externes, il ne va pas forcement
rechercher la même et dans le même ordre (donc si elles réagissent
différement, tu plantes sans savoir pourquoi)
- certains codes d'erreur ne sont pas les mêmes, voire certaines erreurs
ne
sont pas soulevées en mode debug
- certains appels système ne sont pas exécutés pareil (en particulier
l'appel msgbox!).
La seule solution que j'ai trouvé est de compiler et tester ! En plus, il
faut supprimer (sauf impossibilité) tous les "On Error Resume Next" pour
pouvoir identifier l'endroit exact ou tu as des problèmes ...
"Geofrey van Hecke" a écrit :En runtime, j'ai un client (écrit en javascript) qui invoque des
fonctions
exposées par un webservice. Ce dernier écrit en C# dialogue avec une
application serveur écrite en VB6 (mon serveur est un ActiveX Exe). Le
tout
fonctionne parfaitement.
Mon problème apparait, lorsque j'essaie de debuger mon ActiveX Exe.
Lorsque j'ouvre mon projet VB et que je le démarre en mode debug pour
faire
du "Step by step", mon webservice ne parvient plus à s'y connecter. Le
client ne peut donc pas interagir avec l'application serveur car le
webservice qui sert d'intermédiaire ne parvient pas à dialoguer avec le
serveur.
Y'aurait-il quelqu'un qui aurait déjà expérimenter cela et qui a trouvé
une
solution ?
D'avance merci.
Merci fort bien pour ta réponse.
En compilant mon serveur, Visual Basic s'occupe également de déclarer mon
ActiveX Exe dans la base de registre de Windows (pour que le DCOM soit
fonctionnel).
Ensuite, pour que le webservice puisse fonctionner, j'exécute d'abord
commande "tlbimp.exe serveur.exe" qui porduit en retour un fichier
"serveur.dll" que je référence dans mon webservice. Ainsi fait, mon
webservice peut être compiler et l'Interop entre le webservice et l'ActiveX
Exe fonctionne alors parfaitement.
Mon hypothèse est qu'en mode debug, l'Interop ne fonctionne plus car
l'ActiveX Exe s'éxécute dans un contexte différent et que le protocol DCOM
ne fonctionne alors plus pareillement.
J'aimerais vivement trouver un moyen de procéder pour que l'Interop
fonctionne tout de même. Y'a-t-il une quelconque commande tel que
"tlbimp.exe" qui doit être exécuter auparavant ? Je l'ignore...
Si quelqu'un connait la réponse... Merci de me mettre sur la piste
Merci fort bien pour ta réponse.
En compilant mon serveur, Visual Basic s'occupe également de déclarer mon
ActiveX Exe dans la base de registre de Windows (pour que le DCOM soit
fonctionnel).
Ensuite, pour que le webservice puisse fonctionner, j'exécute d'abord
commande "tlbimp.exe serveur.exe" qui porduit en retour un fichier
"serveur.dll" que je référence dans mon webservice. Ainsi fait, mon
webservice peut être compiler et l'Interop entre le webservice et l'ActiveX
Exe fonctionne alors parfaitement.
Mon hypothèse est qu'en mode debug, l'Interop ne fonctionne plus car
l'ActiveX Exe s'éxécute dans un contexte différent et que le protocol DCOM
ne fonctionne alors plus pareillement.
J'aimerais vivement trouver un moyen de procéder pour que l'Interop
fonctionne tout de même. Y'a-t-il une quelconque commande tel que
"tlbimp.exe" qui doit être exécuter auparavant ? Je l'ignore...
Si quelqu'un connait la réponse... Merci de me mettre sur la piste
Merci fort bien pour ta réponse.
En compilant mon serveur, Visual Basic s'occupe également de déclarer mon
ActiveX Exe dans la base de registre de Windows (pour que le DCOM soit
fonctionnel).
Ensuite, pour que le webservice puisse fonctionner, j'exécute d'abord
commande "tlbimp.exe serveur.exe" qui porduit en retour un fichier
"serveur.dll" que je référence dans mon webservice. Ainsi fait, mon
webservice peut être compiler et l'Interop entre le webservice et l'ActiveX
Exe fonctionne alors parfaitement.
Mon hypothèse est qu'en mode debug, l'Interop ne fonctionne plus car
l'ActiveX Exe s'éxécute dans un contexte différent et que le protocol DCOM
ne fonctionne alors plus pareillement.
J'aimerais vivement trouver un moyen de procéder pour que l'Interop
fonctionne tout de même. Y'a-t-il une quelconque commande tel que
"tlbimp.exe" qui doit être exécuter auparavant ? Je l'ignore...
Si quelqu'un connait la réponse... Merci de me mettre sur la piste
Bonjour,
1. tel que tu le décris, cela n'aura aucune chance de fonctionner :
lorsque
ton serveur tourne en mode tests, c'est Visual Basic le programme, et pas
Serveur.exe
2. je doute que tlbimp.exe marche avec lae programme Visual Basic, mais ça
ne résoudra en rien ton problème, puisque ton appli cliente ne saura pas
l'appeler!
3. vu sur le net, la suggestion consiste à développer une petite
application
pour tester la partie serveur de l'appli
Donc, si ton appli cliente est en VB aussi, tu mets les deux dans un même
paquet, et tu teste ton client, qui apelle ton serveur, le tout sous
debug!
Ce qu'il faudrait démonter!
Tiens nous au courant de tes résultats.
"Geofrey van Hecke" a écrit :Merci fort bien pour ta réponse.
En compilant mon serveur, Visual Basic s'occupe également de déclarer mon
ActiveX Exe dans la base de registre de Windows (pour que le DCOM soit
fonctionnel).
Ensuite, pour que le webservice puisse fonctionner, j'exécute d'abord
commande "tlbimp.exe serveur.exe" qui porduit en retour un fichier
"serveur.dll" que je référence dans mon webservice. Ainsi fait, mon
webservice peut être compiler et l'Interop entre le webservice et
l'ActiveX
Exe fonctionne alors parfaitement.
Mon hypothèse est qu'en mode debug, l'Interop ne fonctionne plus car
l'ActiveX Exe s'éxécute dans un contexte différent et que le protocol
DCOM
ne fonctionne alors plus pareillement.
J'aimerais vivement trouver un moyen de procéder pour que l'Interop
fonctionne tout de même. Y'a-t-il une quelconque commande tel que
"tlbimp.exe" qui doit être exécuter auparavant ? Je l'ignore...
Si quelqu'un connait la réponse... Merci de me mettre sur la piste
Bonjour,
1. tel que tu le décris, cela n'aura aucune chance de fonctionner :
lorsque
ton serveur tourne en mode tests, c'est Visual Basic le programme, et pas
Serveur.exe
2. je doute que tlbimp.exe marche avec lae programme Visual Basic, mais ça
ne résoudra en rien ton problème, puisque ton appli cliente ne saura pas
l'appeler!
3. vu sur le net, la suggestion consiste à développer une petite
application
pour tester la partie serveur de l'appli
Donc, si ton appli cliente est en VB aussi, tu mets les deux dans un même
paquet, et tu teste ton client, qui apelle ton serveur, le tout sous
debug!
Ce qu'il faudrait démonter!
Tiens nous au courant de tes résultats.
"Geofrey van Hecke" a écrit :
Merci fort bien pour ta réponse.
En compilant mon serveur, Visual Basic s'occupe également de déclarer mon
ActiveX Exe dans la base de registre de Windows (pour que le DCOM soit
fonctionnel).
Ensuite, pour que le webservice puisse fonctionner, j'exécute d'abord
commande "tlbimp.exe serveur.exe" qui porduit en retour un fichier
"serveur.dll" que je référence dans mon webservice. Ainsi fait, mon
webservice peut être compiler et l'Interop entre le webservice et
l'ActiveX
Exe fonctionne alors parfaitement.
Mon hypothèse est qu'en mode debug, l'Interop ne fonctionne plus car
l'ActiveX Exe s'éxécute dans un contexte différent et que le protocol
DCOM
ne fonctionne alors plus pareillement.
J'aimerais vivement trouver un moyen de procéder pour que l'Interop
fonctionne tout de même. Y'a-t-il une quelconque commande tel que
"tlbimp.exe" qui doit être exécuter auparavant ? Je l'ignore...
Si quelqu'un connait la réponse... Merci de me mettre sur la piste
Bonjour,
1. tel que tu le décris, cela n'aura aucune chance de fonctionner :
lorsque
ton serveur tourne en mode tests, c'est Visual Basic le programme, et pas
Serveur.exe
2. je doute que tlbimp.exe marche avec lae programme Visual Basic, mais ça
ne résoudra en rien ton problème, puisque ton appli cliente ne saura pas
l'appeler!
3. vu sur le net, la suggestion consiste à développer une petite
application
pour tester la partie serveur de l'appli
Donc, si ton appli cliente est en VB aussi, tu mets les deux dans un même
paquet, et tu teste ton client, qui apelle ton serveur, le tout sous
debug!
Ce qu'il faudrait démonter!
Tiens nous au courant de tes résultats.
"Geofrey van Hecke" a écrit :Merci fort bien pour ta réponse.
En compilant mon serveur, Visual Basic s'occupe également de déclarer mon
ActiveX Exe dans la base de registre de Windows (pour que le DCOM soit
fonctionnel).
Ensuite, pour que le webservice puisse fonctionner, j'exécute d'abord
commande "tlbimp.exe serveur.exe" qui porduit en retour un fichier
"serveur.dll" que je référence dans mon webservice. Ainsi fait, mon
webservice peut être compiler et l'Interop entre le webservice et
l'ActiveX
Exe fonctionne alors parfaitement.
Mon hypothèse est qu'en mode debug, l'Interop ne fonctionne plus car
l'ActiveX Exe s'éxécute dans un contexte différent et que le protocol
DCOM
ne fonctionne alors plus pareillement.
J'aimerais vivement trouver un moyen de procéder pour que l'Interop
fonctionne tout de même. Y'a-t-il une quelconque commande tel que
"tlbimp.exe" qui doit être exécuter auparavant ? Je l'ignore...
Si quelqu'un connait la réponse... Merci de me mettre sur la piste
Je suis d'accord avec toi pour le premier point. Mon intuition était
également que ca ne fonctionne pas car en mode Debug sous Visual Basic, mon
programme s'exécute sous le nom de VB6.exe
Par contre tlbimp.exe, fonctionne parfaitement puisque je l'utilise. Je
compile mon webservice avec une référence vers mon "serveur.dll" généré par
tlbimp. En mode normal, j'ouvre mon portal web depuis IE et celui-ci reçoit
bien les réponses du serveur relayées par le webservice. Tout interagit donc
bien.
J'ai également des client VB et avec lesquels je peux facilement debugger le
serveur. Mais ceux-ci ne disposent pas de toute les nouvelles
fonctionnalités du client léger. Pour tester les nouvelles fonctionnalités
je souhaiterais donc débuger le serveur + client léger aussi facilement que
je le fait avec le serveur + client lourd.
Je vais de plus en plus vers une version client léger. A terme, mon client
lourd ne plus être maintenu.
Une idée ?
"SAISAS" wrote in message
news:
> Bonjour,
>
> 1. tel que tu le décris, cela n'aura aucune chance de fonctionner :
> lorsque
> ton serveur tourne en mode tests, c'est Visual Basic le programme, et pas
> Serveur.exe
>
> 2. je doute que tlbimp.exe marche avec lae programme Visual Basic, mais ça
> ne résoudra en rien ton problème, puisque ton appli cliente ne saura pas
> l'appeler!
>
> 3. vu sur le net, la suggestion consiste à développer une petite
> application
> pour tester la partie serveur de l'appli
>
> Donc, si ton appli cliente est en VB aussi, tu mets les deux dans un même
> paquet, et tu teste ton client, qui apelle ton serveur, le tout sous
> debug!
> Ce qu'il faudrait démonter!
>
> Tiens nous au courant de tes résultats.
>
> "Geofrey van Hecke" a écrit :
>
>> Merci fort bien pour ta réponse.
>>
>> En compilant mon serveur, Visual Basic s'occupe également de déclarer mon
>> ActiveX Exe dans la base de registre de Windows (pour que le DCOM soit
>> fonctionnel).
>>
>> Ensuite, pour que le webservice puisse fonctionner, j'exécute d'abord
>> commande "tlbimp.exe serveur.exe" qui porduit en retour un fichier
>> "serveur.dll" que je référence dans mon webservice. Ainsi fait, mon
>> webservice peut être compiler et l'Interop entre le webservice et
>> l'ActiveX
>> Exe fonctionne alors parfaitement.
>>
>> Mon hypothèse est qu'en mode debug, l'Interop ne fonctionne plus car
>> l'ActiveX Exe s'éxécute dans un contexte différent et que le protocol
>> DCOM
>> ne fonctionne alors plus pareillement.
>>
>> J'aimerais vivement trouver un moyen de procéder pour que l'Interop
>> fonctionne tout de même. Y'a-t-il une quelconque commande tel que
>> "tlbimp.exe" qui doit être exécuter auparavant ? Je l'ignore...
>>
>> Si quelqu'un connait la réponse... Merci de me mettre sur la piste
>>
>
Je suis d'accord avec toi pour le premier point. Mon intuition était
également que ca ne fonctionne pas car en mode Debug sous Visual Basic, mon
programme s'exécute sous le nom de VB6.exe
Par contre tlbimp.exe, fonctionne parfaitement puisque je l'utilise. Je
compile mon webservice avec une référence vers mon "serveur.dll" généré par
tlbimp. En mode normal, j'ouvre mon portal web depuis IE et celui-ci reçoit
bien les réponses du serveur relayées par le webservice. Tout interagit donc
bien.
J'ai également des client VB et avec lesquels je peux facilement debugger le
serveur. Mais ceux-ci ne disposent pas de toute les nouvelles
fonctionnalités du client léger. Pour tester les nouvelles fonctionnalités
je souhaiterais donc débuger le serveur + client léger aussi facilement que
je le fait avec le serveur + client lourd.
Je vais de plus en plus vers une version client léger. A terme, mon client
lourd ne plus être maintenu.
Une idée ?
"SAISAS" <SAISAS@discussions.microsoft.com> wrote in message
news:DA1BC121-D434-4790-A0EC-CAAA56D02565@microsoft.com...
> Bonjour,
>
> 1. tel que tu le décris, cela n'aura aucune chance de fonctionner :
> lorsque
> ton serveur tourne en mode tests, c'est Visual Basic le programme, et pas
> Serveur.exe
>
> 2. je doute que tlbimp.exe marche avec lae programme Visual Basic, mais ça
> ne résoudra en rien ton problème, puisque ton appli cliente ne saura pas
> l'appeler!
>
> 3. vu sur le net, la suggestion consiste à développer une petite
> application
> pour tester la partie serveur de l'appli
>
> Donc, si ton appli cliente est en VB aussi, tu mets les deux dans un même
> paquet, et tu teste ton client, qui apelle ton serveur, le tout sous
> debug!
> Ce qu'il faudrait démonter!
>
> Tiens nous au courant de tes résultats.
>
> "Geofrey van Hecke" a écrit :
>
>> Merci fort bien pour ta réponse.
>>
>> En compilant mon serveur, Visual Basic s'occupe également de déclarer mon
>> ActiveX Exe dans la base de registre de Windows (pour que le DCOM soit
>> fonctionnel).
>>
>> Ensuite, pour que le webservice puisse fonctionner, j'exécute d'abord
>> commande "tlbimp.exe serveur.exe" qui porduit en retour un fichier
>> "serveur.dll" que je référence dans mon webservice. Ainsi fait, mon
>> webservice peut être compiler et l'Interop entre le webservice et
>> l'ActiveX
>> Exe fonctionne alors parfaitement.
>>
>> Mon hypothèse est qu'en mode debug, l'Interop ne fonctionne plus car
>> l'ActiveX Exe s'éxécute dans un contexte différent et que le protocol
>> DCOM
>> ne fonctionne alors plus pareillement.
>>
>> J'aimerais vivement trouver un moyen de procéder pour que l'Interop
>> fonctionne tout de même. Y'a-t-il une quelconque commande tel que
>> "tlbimp.exe" qui doit être exécuter auparavant ? Je l'ignore...
>>
>> Si quelqu'un connait la réponse... Merci de me mettre sur la piste
>>
>
Je suis d'accord avec toi pour le premier point. Mon intuition était
également que ca ne fonctionne pas car en mode Debug sous Visual Basic, mon
programme s'exécute sous le nom de VB6.exe
Par contre tlbimp.exe, fonctionne parfaitement puisque je l'utilise. Je
compile mon webservice avec une référence vers mon "serveur.dll" généré par
tlbimp. En mode normal, j'ouvre mon portal web depuis IE et celui-ci reçoit
bien les réponses du serveur relayées par le webservice. Tout interagit donc
bien.
J'ai également des client VB et avec lesquels je peux facilement debugger le
serveur. Mais ceux-ci ne disposent pas de toute les nouvelles
fonctionnalités du client léger. Pour tester les nouvelles fonctionnalités
je souhaiterais donc débuger le serveur + client léger aussi facilement que
je le fait avec le serveur + client lourd.
Je vais de plus en plus vers une version client léger. A terme, mon client
lourd ne plus être maintenu.
Une idée ?
"SAISAS" wrote in message
news:
> Bonjour,
>
> 1. tel que tu le décris, cela n'aura aucune chance de fonctionner :
> lorsque
> ton serveur tourne en mode tests, c'est Visual Basic le programme, et pas
> Serveur.exe
>
> 2. je doute que tlbimp.exe marche avec lae programme Visual Basic, mais ça
> ne résoudra en rien ton problème, puisque ton appli cliente ne saura pas
> l'appeler!
>
> 3. vu sur le net, la suggestion consiste à développer une petite
> application
> pour tester la partie serveur de l'appli
>
> Donc, si ton appli cliente est en VB aussi, tu mets les deux dans un même
> paquet, et tu teste ton client, qui apelle ton serveur, le tout sous
> debug!
> Ce qu'il faudrait démonter!
>
> Tiens nous au courant de tes résultats.
>
> "Geofrey van Hecke" a écrit :
>
>> Merci fort bien pour ta réponse.
>>
>> En compilant mon serveur, Visual Basic s'occupe également de déclarer mon
>> ActiveX Exe dans la base de registre de Windows (pour que le DCOM soit
>> fonctionnel).
>>
>> Ensuite, pour que le webservice puisse fonctionner, j'exécute d'abord
>> commande "tlbimp.exe serveur.exe" qui porduit en retour un fichier
>> "serveur.dll" que je référence dans mon webservice. Ainsi fait, mon
>> webservice peut être compiler et l'Interop entre le webservice et
>> l'ActiveX
>> Exe fonctionne alors parfaitement.
>>
>> Mon hypothèse est qu'en mode debug, l'Interop ne fonctionne plus car
>> l'ActiveX Exe s'éxécute dans un contexte différent et que le protocol
>> DCOM
>> ne fonctionne alors plus pareillement.
>>
>> J'aimerais vivement trouver un moyen de procéder pour que l'Interop
>> fonctionne tout de même. Y'a-t-il une quelconque commande tel que
>> "tlbimp.exe" qui doit être exécuter auparavant ? Je l'ignore...
>>
>> Si quelqu'un connait la réponse... Merci de me mettre sur la piste
>>
>