J'ai un Web Service qui utilise un jeu de DLL (plugins - C++ non
managé). Ces DLL implémentent une même interface.
J'arrive à invoquer les méthodes des 2 premières DLL sans problème, où
que soient les DLL.
Par contre, quand j'utilise la 3° DLL, lors de l'invocation d'une
méthodes, la page se charge indéfiniment... pas de time-out apparemment.
Ces 3 DLL sont chargées via une DLL faite, elle, en C#. Cette dernière
propose les mêmes méthodes pour chacune des DLL. Pourquoi celà
marche-t-il avec 2 des 3 DLL ? Aucune idée... Le schéma d'invaction est
pourtant le même pour chacune des DLL. Les DLL exposent les mêmes
méthodes sous les même signatures.
Je n'arrive pas à accéder à cette troisième DLL. Impossible d'y rentrer
avec le debugger (debuggage de code non managé à 'True' et j'ai bien mis
les dépendances... fonctionne avec les autres DLL - je dispose des
sources, le timestamp du pdb correspond à la DLL associée).
public int mdmSetUser(string pLogin, string pPassword, string pAccount)
{
MethodInfo method = m_dllMethodList.GetMethod("mdmSetUser");
return (int)method.Invoke
(null, new Object[]{ pLogin, pPassword, pAccount });
}
Le blocage se fait sur le return.
Le WS dispose d'une WebMethod SetUser() qui appelle tout simplement
mdmSetUser()
Les différences entre les DLL (elles font exactement les mêmes choses) :
- la première utilise une application externe : Manreo Warehouse,
- la seconde utilise le système local : disque dur,
- la troisième utilise ADO/MySQL.
Voilà, si qq'un peut m'aider, ça serait sympa. 3 jours que je bloque !
Merci anticipé.
wuaueng.dll (2856) SUS20ClientDataStore: Le moteur de base de données a démarré une nouvelle instance (0). wuauclt (2856) Le moteur de base de données 5.01.2600.2180 est démarré. wuauclt (440) Le moteur de base de données est arrêté. wuaueng.dll (440) SUS20ClientDataStore: Le moteur de base de données a arrêté une instance (0).
-- Delf
Delf wrote:
[...]
Dans le Log Event Application :
wuaueng.dll (2856) SUS20ClientDataStore: Le moteur de base de données a
démarré une nouvelle instance (0).
wuauclt (2856) Le moteur de base de données 5.01.2600.2180 est démarré.
wuauclt (440) Le moteur de base de données est arrêté.
wuaueng.dll (440) SUS20ClientDataStore: Le moteur de base de données a
arrêté une instance (0).
wuaueng.dll (2856) SUS20ClientDataStore: Le moteur de base de données a démarré une nouvelle instance (0). wuauclt (2856) Le moteur de base de données 5.01.2600.2180 est démarré. wuauclt (440) Le moteur de base de données est arrêté. wuaueng.dll (440) SUS20ClientDataStore: Le moteur de base de données a arrêté une instance (0).
-- Delf
Simon Mourier
La 3eme DLL doit faire quelque chose de spécial qui ne tourne pas dans un Web Service. Surtout si l'ensemble fonctionne en Winform.
Rien ne garantit à priori qu'un code écrit pour fonctionner dans un contexte de type desktop (Winform) va fonctionner sans problème dans un service. Cela peut-être dû à des problèmes de droits (accès à des fichiers), ou d'accès au registre (par exemple la clé USER n'est pas forcément chargée en fonction de l'identité sous laquelle fonctionne le service), mais pas uniquement (pas d'environnement graphique, ...)
Simon. www.softfluent.com
"Delf" a écrit dans le message de news: 427f66dc$0$312$
Bonjour.
J'ai un Web Service qui utilise un jeu de DLL (plugins - C++ non managé). Ces DLL implémentent une même interface.
J'arrive à invoquer les méthodes des 2 premières DLL sans problème, où que soient les DLL.
Par contre, quand j'utilise la 3° DLL, lors de l'invocation d'une méthodes, la page se charge indéfiniment... pas de time-out apparemment.
Ces 3 DLL sont chargées via une DLL faite, elle, en C#. Cette dernière propose les mêmes méthodes pour chacune des DLL. Pourquoi celà marche-t-il avec 2 des 3 DLL ? Aucune idée... Le schéma d'invaction est pourtant le même pour chacune des DLL. Les DLL exposent les mêmes méthodes sous les même signatures.
Je n'arrive pas à accéder à cette troisième DLL. Impossible d'y rentrer avec le debugger (debuggage de code non managé à 'True' et j'ai bien mis les dépendances... fonctionne avec les autres DLL - je dispose des sources, le timestamp du pdb correspond à la DLL associée).
public int mdmSetUser(string pLogin, string pPassword, string pAccount) { MethodInfo method = m_dllMethodList.GetMethod("mdmSetUser"); return (int)method.Invoke (null, new Object[]{ pLogin, pPassword, pAccount }); }
Le blocage se fait sur le return.
Le WS dispose d'une WebMethod SetUser() qui appelle tout simplement mdmSetUser()
Les différences entre les DLL (elles font exactement les mêmes choses) :
- la première utilise une application externe : Manreo Warehouse, - la seconde utilise le système local : disque dur, - la troisième utilise ADO/MySQL.
Voilà, si qq'un peut m'aider, ça serait sympa. 3 jours que je bloque ! Merci anticipé.
-- Delf
La 3eme DLL doit faire quelque chose de spécial qui ne tourne pas dans un
Web Service. Surtout si l'ensemble fonctionne en Winform.
Rien ne garantit à priori qu'un code écrit pour fonctionner dans un contexte
de type desktop (Winform) va fonctionner sans problème dans un service. Cela
peut-être dû à des problèmes de droits (accès à des fichiers), ou d'accès au
registre (par exemple la clé USER n'est pas forcément chargée en fonction de
l'identité sous laquelle fonctionne le service), mais pas uniquement (pas
d'environnement graphique, ...)
Simon.
www.softfluent.com
"Delf" <abuse@wanadoo.fr> a écrit dans le message de news:
427f66dc$0$312$626a14ce@news.free.fr...
Bonjour.
J'ai un Web Service qui utilise un jeu de DLL (plugins - C++ non managé).
Ces DLL implémentent une même interface.
J'arrive à invoquer les méthodes des 2 premières DLL sans problème, où que
soient les DLL.
Par contre, quand j'utilise la 3° DLL, lors de l'invocation d'une
méthodes, la page se charge indéfiniment... pas de time-out apparemment.
Ces 3 DLL sont chargées via une DLL faite, elle, en C#. Cette dernière
propose les mêmes méthodes pour chacune des DLL. Pourquoi celà marche-t-il
avec 2 des 3 DLL ? Aucune idée... Le schéma d'invaction est pourtant le
même pour chacune des DLL. Les DLL exposent les mêmes méthodes sous les
même signatures.
Je n'arrive pas à accéder à cette troisième DLL. Impossible d'y rentrer
avec le debugger (debuggage de code non managé à 'True' et j'ai bien mis
les dépendances... fonctionne avec les autres DLL - je dispose des
sources, le timestamp du pdb correspond à la DLL associée).
public int mdmSetUser(string pLogin, string pPassword, string pAccount)
{
MethodInfo method = m_dllMethodList.GetMethod("mdmSetUser");
return (int)method.Invoke
(null, new Object[]{ pLogin, pPassword, pAccount });
}
Le blocage se fait sur le return.
Le WS dispose d'une WebMethod SetUser() qui appelle tout simplement
mdmSetUser()
Les différences entre les DLL (elles font exactement les mêmes choses) :
- la première utilise une application externe : Manreo Warehouse,
- la seconde utilise le système local : disque dur,
- la troisième utilise ADO/MySQL.
Voilà, si qq'un peut m'aider, ça serait sympa. 3 jours que je bloque !
Merci anticipé.
La 3eme DLL doit faire quelque chose de spécial qui ne tourne pas dans un Web Service. Surtout si l'ensemble fonctionne en Winform.
Rien ne garantit à priori qu'un code écrit pour fonctionner dans un contexte de type desktop (Winform) va fonctionner sans problème dans un service. Cela peut-être dû à des problèmes de droits (accès à des fichiers), ou d'accès au registre (par exemple la clé USER n'est pas forcément chargée en fonction de l'identité sous laquelle fonctionne le service), mais pas uniquement (pas d'environnement graphique, ...)
Simon. www.softfluent.com
"Delf" a écrit dans le message de news: 427f66dc$0$312$
Bonjour.
J'ai un Web Service qui utilise un jeu de DLL (plugins - C++ non managé). Ces DLL implémentent une même interface.
J'arrive à invoquer les méthodes des 2 premières DLL sans problème, où que soient les DLL.
Par contre, quand j'utilise la 3° DLL, lors de l'invocation d'une méthodes, la page se charge indéfiniment... pas de time-out apparemment.
Ces 3 DLL sont chargées via une DLL faite, elle, en C#. Cette dernière propose les mêmes méthodes pour chacune des DLL. Pourquoi celà marche-t-il avec 2 des 3 DLL ? Aucune idée... Le schéma d'invaction est pourtant le même pour chacune des DLL. Les DLL exposent les mêmes méthodes sous les même signatures.
Je n'arrive pas à accéder à cette troisième DLL. Impossible d'y rentrer avec le debugger (debuggage de code non managé à 'True' et j'ai bien mis les dépendances... fonctionne avec les autres DLL - je dispose des sources, le timestamp du pdb correspond à la DLL associée).
public int mdmSetUser(string pLogin, string pPassword, string pAccount) { MethodInfo method = m_dllMethodList.GetMethod("mdmSetUser"); return (int)method.Invoke (null, new Object[]{ pLogin, pPassword, pAccount }); }
Le blocage se fait sur le return.
Le WS dispose d'une WebMethod SetUser() qui appelle tout simplement mdmSetUser()
Les différences entre les DLL (elles font exactement les mêmes choses) :
- la première utilise une application externe : Manreo Warehouse, - la seconde utilise le système local : disque dur, - la troisième utilise ADO/MySQL.
Voilà, si qq'un peut m'aider, ça serait sympa. 3 jours que je bloque ! Merci anticipé.
-- Delf
Delf
Simon Mourier wrote:
La 3eme DLL doit faire quelque chose de spécial qui ne tourne pas dans un Web Service. Surtout si l'ensemble fonctionne en Winform.
Rien ne garantit à priori qu'un code écrit pour fonctionner dans un contexte de type desktop (Winform) va fonctionner sans problème dans un service. Cela peut-être dû à des problèmes de droits (accès à des fichiers), ou d'accès au registre (par exemple la clé USER n'est pas forcément chargée en fonction de l'identité sous laquelle fonctionne le service), mais pas uniquement (pas d'environnement graphique, ...)
Finalement, c'était du à ADO...
-- Delf
Simon Mourier wrote:
La 3eme DLL doit faire quelque chose de spécial qui ne tourne pas dans un
Web Service. Surtout si l'ensemble fonctionne en Winform.
Rien ne garantit à priori qu'un code écrit pour fonctionner dans un contexte
de type desktop (Winform) va fonctionner sans problème dans un service. Cela
peut-être dû à des problèmes de droits (accès à des fichiers), ou d'accès au
registre (par exemple la clé USER n'est pas forcément chargée en fonction de
l'identité sous laquelle fonctionne le service), mais pas uniquement (pas
d'environnement graphique, ...)
La 3eme DLL doit faire quelque chose de spécial qui ne tourne pas dans un Web Service. Surtout si l'ensemble fonctionne en Winform.
Rien ne garantit à priori qu'un code écrit pour fonctionner dans un contexte de type desktop (Winform) va fonctionner sans problème dans un service. Cela peut-être dû à des problèmes de droits (accès à des fichiers), ou d'accès au registre (par exemple la clé USER n'est pas forcément chargée en fonction de l'identité sous laquelle fonctionne le service), mais pas uniquement (pas d'environnement graphique, ...)
