CGI en C++ qui appelle une DLL .NET sur windows server 2004
3 réponses
ivan.martinac
Un CGI écrit en C++ qui appelle une DLL en managed C++.
J'ai deux serveurs windows 2003 ; sur le premier tout fonctionne
normalement (DOS et navigateur), mais pas sur le second (DOS
seulement). Le programme fonctionne bien s'il est appelé à partir
d'une fenêtre DOS, mais pas depuis un navigateur pour la seconde
machine.
J'ai comparé les configurations sur les deux serveurs, sans trouer de
différence:
- les droits sur les fichiers et répertoires sont corrects
- dans IIS/Web Service Extensions, les extensions CGI sont autorisées
- mon répertoire virtuel accepte l'exécution de sciptes
Le message d'erreur dans le navigateur est :
CGI Error
The specified CGI application misbehaved by not returning a complete
set of HTTP headers.
ce qui doit vouloir dire que l'application n'a pas réussi à
s'initialiser (à charger la DLL ?).
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Carsten HERRMANN
Bonjour,
si ça marche sur un ordinateur, mais pas sur l'autre, c'est à cause d'une configuration différente.
La version du .NET Framework installée est peut être différente ou il te manque quelque chose sur la deuxième machine (dll,...). Cherche "deployment" dans l'aide.
Ce qu'il faut encore sur le deuxième ordinateur, a été installé en passant sur le premier avec un autre programme (p.ex. environment de développement ...) ou service pack.
A+ Carsten
-- Adresse e-mail antispam : E-mail sans NO_SPAM mentionné dans l'objet est automatiquement écrasé.
Bonjour,
si ça marche sur un ordinateur,
mais pas sur l'autre,
c'est à cause d'une configuration différente.
La version du .NET Framework installée est peut être différente ou
il te manque quelque chose sur la deuxième machine (dll,...).
Cherche "deployment" dans l'aide.
Ce qu'il faut encore sur le deuxième ordinateur,
a été installé en passant sur le premier avec un autre programme
(p.ex. environment de développement ...)
ou service pack.
A+
Carsten
--
Adresse e-mail antispam :
E-mail sans NO_SPAM mentionné dans l'objet est automatiquement écrasé.
si ça marche sur un ordinateur, mais pas sur l'autre, c'est à cause d'une configuration différente.
La version du .NET Framework installée est peut être différente ou il te manque quelque chose sur la deuxième machine (dll,...). Cherche "deployment" dans l'aide.
Ce qu'il faut encore sur le deuxième ordinateur, a été installé en passant sur le premier avec un autre programme (p.ex. environment de développement ...) ou service pack.
A+ Carsten
-- Adresse e-mail antispam : E-mail sans NO_SPAM mentionné dans l'objet est automatiquement écrasé.
ivan.martinac
Carsten, merci pour ta réponse mais je ne pense pas qu'il manque une DLL, car lorsque je lance le programme à partir d'un shell DOS, il s'exécute normalement.
Mon EXE et ma DLL sont dans le même répertoire. Lorsqu'un exécutable démarre, il cherche d'abord ses DLL dans son répertoire, puis dans le répertoire système. Ce qui doit se passer, c'est que lorsque l'application est démarrée par IIS, son répertoire de travail est défini différemment, ce qui fait qu'il ne trouve pas sa DLL. Ce n'est qu'une hypothèse, quelqu'un en saurait-il plus ?
Carsten,
merci pour ta réponse mais je ne pense pas qu'il manque une DLL, car
lorsque je lance le programme à partir d'un shell DOS, il s'exécute
normalement.
Mon EXE et ma DLL sont dans le même répertoire. Lorsqu'un exécutable
démarre, il cherche d'abord ses DLL dans son répertoire, puis dans le
répertoire système.
Ce qui doit se passer, c'est que lorsque l'application est démarrée
par IIS, son répertoire de travail est défini différemment, ce qui
fait qu'il ne trouve pas sa DLL.
Ce n'est qu'une hypothèse, quelqu'un en saurait-il plus ?
Carsten, merci pour ta réponse mais je ne pense pas qu'il manque une DLL, car lorsque je lance le programme à partir d'un shell DOS, il s'exécute normalement.
Mon EXE et ma DLL sont dans le même répertoire. Lorsqu'un exécutable démarre, il cherche d'abord ses DLL dans son répertoire, puis dans le répertoire système. Ce qui doit se passer, c'est que lorsque l'application est démarrée par IIS, son répertoire de travail est défini différemment, ce qui fait qu'il ne trouve pas sa DLL. Ce n'est qu'une hypothèse, quelqu'un en saurait-il plus ?
ivan.martinac
MISE A JOUR: le programme échoue à l'initialisation parce qu'il ne trouve pas la DLL.
J'ai tout d'abord supprimé le lien dynamique vers la DLL et l'ai remplacé par des appels à LoadLibrary et GetProcAddress, pour avoir des messages d'erreur plus explicites. L'appel à LoadLibrary retourne NULL, même si la DLL se trouve dans le même répertoire que l'EXE. J'ai essayé de placer la DLL dans le répertoire système de windows, ou de changer la variable d'environnement PATH, mais ça n'a rien changé.
Remarquez que l'application fonctionne bien lorsqu'elle est appelée à partir du DOS, mais pas en tant que CGI par IIS.
Ensuite j'ai indiqué le chemin complet vers la DLL dans l'appel à LoadLibrary, et ça a fonctionné ! Cela signifie que même si la DLL est dans le même répertoire, l'EXE n'arrive pas à la trouver.
Il semble que lorsqu'elle est lancée par IIS, l'application se comporte comme si elle était dans un autre répertoire, c'est-à-dire comme si son répertoire de travail était fixé à une autre valeur.
Comme nous avons un autre Windows Server 2003 sur lequel le programme fonctionne normalement, je suppose qu'il y a un paramètre qui diffère que je n'arrive pas à trouver.
Quelqu'un sait-il pourquoi le répertoire de travail est modifié et comment le ramener à son état "normal" ? Cela a-t-il quelque chose à voir avec les Application Pools de IIS?
MISE A JOUR: le programme échoue à l'initialisation parce qu'il ne
trouve pas la DLL.
J'ai tout d'abord supprimé le lien dynamique vers la DLL et l'ai
remplacé par des appels à LoadLibrary et GetProcAddress, pour avoir
des messages d'erreur plus explicites. L'appel à LoadLibrary retourne
NULL, même si la DLL se trouve dans le même répertoire que l'EXE.
J'ai essayé de placer la DLL dans le répertoire système de windows,
ou de changer la variable d'environnement PATH, mais ça n'a rien
changé.
Remarquez que l'application fonctionne bien lorsqu'elle est appelée à
partir du DOS, mais pas en tant que CGI par IIS.
Ensuite j'ai indiqué le chemin complet vers la DLL dans l'appel à
LoadLibrary, et ça a fonctionné ! Cela signifie que même si la DLL
est dans le même répertoire, l'EXE n'arrive pas à la trouver.
Il semble que lorsqu'elle est lancée par IIS, l'application se
comporte comme si elle était dans un autre répertoire, c'est-à-dire
comme si son répertoire de travail était fixé à une autre valeur.
Comme nous avons un autre Windows Server 2003 sur lequel le programme
fonctionne normalement, je suppose qu'il y a un paramètre qui diffère
que je n'arrive pas à trouver.
Quelqu'un sait-il pourquoi le répertoire de travail est modifié et
comment le ramener à son état "normal" ?
Cela a-t-il quelque chose à voir avec les Application Pools de IIS?
MISE A JOUR: le programme échoue à l'initialisation parce qu'il ne trouve pas la DLL.
J'ai tout d'abord supprimé le lien dynamique vers la DLL et l'ai remplacé par des appels à LoadLibrary et GetProcAddress, pour avoir des messages d'erreur plus explicites. L'appel à LoadLibrary retourne NULL, même si la DLL se trouve dans le même répertoire que l'EXE. J'ai essayé de placer la DLL dans le répertoire système de windows, ou de changer la variable d'environnement PATH, mais ça n'a rien changé.
Remarquez que l'application fonctionne bien lorsqu'elle est appelée à partir du DOS, mais pas en tant que CGI par IIS.
Ensuite j'ai indiqué le chemin complet vers la DLL dans l'appel à LoadLibrary, et ça a fonctionné ! Cela signifie que même si la DLL est dans le même répertoire, l'EXE n'arrive pas à la trouver.
Il semble que lorsqu'elle est lancée par IIS, l'application se comporte comme si elle était dans un autre répertoire, c'est-à-dire comme si son répertoire de travail était fixé à une autre valeur.
Comme nous avons un autre Windows Server 2003 sur lequel le programme fonctionne normalement, je suppose qu'il y a un paramètre qui diffère que je n'arrive pas à trouver.
Quelqu'un sait-il pourquoi le répertoire de travail est modifié et comment le ramener à son état "normal" ? Cela a-t-il quelque chose à voir avec les Application Pools de IIS?
