Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

WebService déconnecté après utilisation d'un ocx.

3 réponses
Avatar
Nicolas L.
Bonjour,

Je suis dans une application Winform C# VS2003 + WebService pour accéder
aux bases de données. avec un cookie de session :
System.Net.CookieContainer()

J'utilise un ocx en c++ qui accède à un document en exécutant un
ShellExecuteInfo à travers une fonction OpenContext(filename,...);
Evidemment je suis obligé d'utiliser cet ocx et ne peut le remplacer par
un autre.

Après appel de cette fonction qui est obligatoire pour utiliser les
opérations suivantes.

Il m'est impossible d'accéder aux WebServices. Je tombe sur une erreur
System.IO.IOExecption due à l'impossibilité d'ouvrir une socket.

J'ai essayé plusieurs pistes comme exécuter l'ocx dans une autre thread
mais ca ne resoud pas le probleme.

using System.Threading;
using System.Runtime.Remoting.Contexts;

[Synchronization(SynchronizationAttribute.REQUIRES_NEW)]
public class classOpenDocument : ContextBoundObject
{

}...

Je me demandais comment créer un deuxième context d'application qui soit
séparé du context normal de mon application.

En effet en winform dans MSDN de partout est écrit "normallement vous
n'avez pas à programmer dans le context..."


D'autre part, pour chercher sur une autre piste comment on peut
fermer-ouvrir une session pour les webservices et savoir si elle a été
totalement ouverte.


En attendant vos réponses,


Nicolas L.

3 réponses

Avatar
Paul Bacelar
Vérifiez que le thread n'ai pas changé d'utilisateur après l'appel.

L'utilisation d'un AppDoamin pour l'appel à l'OCX pourrait permettre un
cloisonnement efficace.

Utilisez les InnerException pour savoir pourquoi la création de socket est
impossible (les Exceptions, c'est comme les poupées gigognes ;-)).
--
Paul Bacelar
MVP VC++



"Nicolas L." wrote in message
news:
Bonjour,

Je suis dans une application Winform C# VS2003 + WebService pour accéder
aux bases de données. avec un cookie de session :
System.Net.CookieContainer()

J'utilise un ocx en c++ qui accède à un document en exécutant un
ShellExecuteInfo à travers une fonction OpenContext(filename,...);
Evidemment je suis obligé d'utiliser cet ocx et ne peut le remplacer par
un autre.

Après appel de cette fonction qui est obligatoire pour utiliser les
opérations suivantes.

Il m'est impossible d'accéder aux WebServices. Je tombe sur une erreur
System.IO.IOExecption due à l'impossibilité d'ouvrir une socket.

J'ai essayé plusieurs pistes comme exécuter l'ocx dans une autre thread
mais ca ne resoud pas le probleme.

using System.Threading;
using System.Runtime.Remoting.Contexts;

[Synchronization(SynchronizationAttribute.REQUIRES_NEW)]
public class classOpenDocument : ContextBoundObject
{

}...

Je me demandais comment créer un deuxième context d'application qui soit
séparé du context normal de mon application.

En effet en winform dans MSDN de partout est écrit "normallement vous
n'avez pas à programmer dans le context..."


D'autre part, pour chercher sur une autre piste comment on peut
fermer-ouvrir une session pour les webservices et savoir si elle a été
totalement ouverte.


En attendant vos réponses,


Nicolas L.


Avatar
Nicolas L.
J'ai créé un nouveau AppDomain et chargé un .dll à l'intérieur qui wrap
mon ocx. Pas de résultat.

J'ai regardé pour les InnerException mais je tombe sur erreur non-gérée
par system.dll puis il me propose d'afficher du code machine. Donc je
n'arrive pas à bien cerner l'erreur.

Nicolas L.

Paul Bacelar a écrit :
Vérifiez que le thread n'ai pas changé d'utilisateur après l'appel.

L'utilisation d'un AppDoamin pour l'appel à l'OCX pourrait permettre un
cloisonnement efficace.

Utilisez les InnerException pour savoir pourquoi la création de socket est
impossible (les Exceptions, c'est comme les poupées gigognes ;-)).


Avatar
Paul Bacelar
Normalement, sur une exception non-gérée un numéro d'exception correspondant
à l'erreur Win32 associé.

Vu la nature de votre application, je pencherais vers une interdiction
d'ouvrir de socket vers l'extérieur que la SandBox du FrameWork fait
respecté.

Vérifiez que l'erreur est bien un accès refusé.

Postez nous un extrait de la call-stack (avec le nom des méthodes non-managé
si possible)

--
Paul Bacelar
MVP VC++

"Nicolas L." wrote in message
news:ez%
J'ai créé un nouveau AppDomain et chargé un .dll à l'intérieur qui wrap
mon ocx. Pas de résultat.

J'ai regardé pour les InnerException mais je tombe sur erreur non-gérée
par system.dll puis il me propose d'afficher du code machine. Donc je
n'arrive pas à bien cerner l'erreur.

Nicolas L.

Paul Bacelar a écrit :
Vérifiez que le thread n'ai pas changé d'utilisateur après l'appel.

L'utilisation d'un AppDoamin pour l'appel à l'OCX pourrait permettre un
cloisonnement efficace.

Utilisez les InnerException pour savoir pourquoi la création de socket
est impossible (les Exceptions, c'est comme les poupées gigognes ;-)).