Compilation et déploiement d'un module Perl sous Windows
52 réponses
Stephane Dupille
Bonjour,
J'ai une machine sur laquelle je dois déployer une appli Perl. J'ai
donc installé ActivePerl dessus. L'appli doit se connecter à une base
Ingres, et donc je dois utiliser le driver DBD::Ingres.
Malheureusement, ce module n'est pas disponible par PPM, je dois donc
le compiler à la main.
J'ai donc installé sur cette machine « Visual C++ 2005 Express
Edition », ainsi que le SDK pour le dev. La compilation se passe plus
ou moins bien (j'ai par exemple été obligé de patcher le Makefile
généré pour remplacer libc.lib par libcmt.lib, la première n'existant
plus). Bref, sur ma machine de dev, ce module marche correctement, les
tests passent avec succès, et mes scripts de tests maison ne détectent
pas d'anomalie.
Maintenant, je dois déployer Perl, et cette appli sur une autre
machine. Particularité : cette machine n'a pas d'accès Internet, entre
autres contraintes un peu chiantes. Afin de pouvoir automatiser ça le
plus possible, j'ai transféré simplement le répertoire C:\Perl de ma
machine de dev vers la machine de test.
En faisant ça Perl fonctionne correctement, mais pas le module
DBD::Ingres. Quand j'essaye de l'utiliser, il me dit que MSVCR80.dll
est introuvable. Visiblement, il me faut un runtime. C'est bien la
peine de se faire chier à compiler un truc pas déployable. Est-ce
qu'il est possible de se passer du runtime ?
J'installe le runtime vcredist_x86.exe sur ma machine de test, je
relance mon appli, et ça me dit toujours que MSVCR80.dll est
introuvable. C'est pas ça qu'il fallait que j'installe ?
J'ai finit par copier le fichier MSVCR80.dll depuis le répertoire
C:\WINNT\winsxs\x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_0de06acd
vers le répertoire C:\Perl\site\lib\auto\DBD\Ingres
Maintenant, quand je lance mon appli, il trouve bien la
bibliothèque, mais ça ne marche toujours pas :
Runtime Error !
R6034
An application has attempt to load the C runtime library incorrectly.
Il faut faire quoi maintenant pour faire marcher ce module ?
Question pour les perliens : est-ce qu'il y aurait un endroit où
trouver un PPM de DBD::Ingres déployable normalement ?
Question pour les windowsiens : est-ce qu'il y aurait un moyen de
pouvoir compiler un machin déployable normalement sans s'emmerder avec
des runtimes pourris qui ne marchent pas ?
Pour info, ma machine de dev est un win2000, ma machine de test un
Win XP pro 2002, et cette appli sera développé sur des machines dont
je ne contrôle absolument pas les versions de Windows installé dessus.
Peut-être suivre les conseils de microsoft : <http://msdn2.microsoft.com/en-US/library/ms235560(VS.80).aspx>
J'ai potassé, j'ai appliqué, mais ça ne marche toujours pas.
Pour rappel, j'essaye de compiler une DLL Ingres.dll. Lors de la compilation, j'ai bien un fichier Ingres.dll.manifest qui est créé, dont voici le contenu : <?xml version='1.0' encoding='UTF-8' standalone='yes'?> <assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'> <dependency> <dependentAssembly> <assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' /> </dependentAssembly> </dependency> </assembly>
Sur la machine cible, j'ai un répertoire c:WindowsWinSxSx86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.050727.42_x-ww_0de06acd/ qui contient bien un msvcr80.dll (et deux autres DLL) et il me dit toujours qu'il n'arrive pas à trouver msvcr80.dll
Bref, rien de changé par rapport à avant. Mais pourquoi est-ce que ce crétin ne trouve pas la DLL ? Pourquoi est-ce que quand je la lui fournit il n'arrive pas à l'utiliser. Pire : mais pourquoi ce con a besoin de cette DLL pourrie ?
Peut-être suivre les conseils de microsoft :
<http://msdn2.microsoft.com/en-US/library/ms235560(VS.80).aspx>
J'ai potassé, j'ai appliqué, mais ça ne marche toujours pas.
Pour rappel, j'essaye de compiler une DLL Ingres.dll. Lors de la
compilation, j'ai bien un fichier Ingres.dll.manifest qui est créé,
dont voici le contenu :
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1'
manifestVersion='1.0'>
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC80.CRT'
version='8.0.50608.0' processorArchitecture='x86'
publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
</dependency>
</assembly>
Sur la machine cible, j'ai un répertoire
c:WindowsWinSxSx86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.050727.42_x-ww_0de06acd/
qui contient bien un msvcr80.dll (et deux autres DLL)
et il me dit toujours qu'il n'arrive pas à trouver msvcr80.dll
Bref, rien de changé par rapport à avant. Mais pourquoi est-ce que
ce crétin ne trouve pas la DLL ? Pourquoi est-ce que quand je la lui
fournit il n'arrive pas à l'utiliser. Pire : mais pourquoi ce con a
besoin de cette DLL pourrie ?
Peut-être suivre les conseils de microsoft : <http://msdn2.microsoft.com/en-US/library/ms235560(VS.80).aspx>
J'ai potassé, j'ai appliqué, mais ça ne marche toujours pas.
Pour rappel, j'essaye de compiler une DLL Ingres.dll. Lors de la compilation, j'ai bien un fichier Ingres.dll.manifest qui est créé, dont voici le contenu : <?xml version='1.0' encoding='UTF-8' standalone='yes'?> <assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'> <dependency> <dependentAssembly> <assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' /> </dependentAssembly> </dependency> </assembly>
Sur la machine cible, j'ai un répertoire c:WindowsWinSxSx86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.050727.42_x-ww_0de06acd/ qui contient bien un msvcr80.dll (et deux autres DLL) et il me dit toujours qu'il n'arrive pas à trouver msvcr80.dll
Bref, rien de changé par rapport à avant. Mais pourquoi est-ce que ce crétin ne trouve pas la DLL ? Pourquoi est-ce que quand je la lui fournit il n'arrive pas à l'utiliser. Pire : mais pourquoi ce con a besoin de cette DLL pourrie ?
Stephane Dupille
Paul Gaborit écrit :
Peut-être suivre les conseils de microsoft : <http://msdn2.microsoft.com/en-US/library/ms235560(VS.80).aspx>
J'ai potassé, j'ai appliqué, mais ça ne marche toujours pas.
Pour rappel, j'essaye de compiler une DLL Ingres.dll. Lors de la compilation, j'ai bien un fichier Ingres.dll.manifest qui est créé, dont voici le contenu : <?xml version='1.0' encoding='UTF-8' standalone='yes'?> <assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'> <dependency> <dependentAssembly> <assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' /> </dependentAssembly> </dependency> </assembly>
Sur la machine cible, j'ai un répertoire c:WindowsWinSxSx86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.050727.42_x-ww_0de06acd/ qui contient bien un msvcr80.dll (et deux autres DLL) et il me dit toujours qu'il n'arrive pas à trouver msvcr80.dll
Bref, rien de changé par rapport à avant. Mais pourquoi est-ce que ce crétin ne trouve pas la DLL ? Pourquoi est-ce que quand je la lui fournit il n'arrive pas à l'utiliser. Pire : mais pourquoi ce con a besoin de cette DLL pourrie ?
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrit :
Peut-être suivre les conseils de microsoft :
<http://msdn2.microsoft.com/en-US/library/ms235560(VS.80).aspx>
J'ai potassé, j'ai appliqué, mais ça ne marche toujours pas.
Pour rappel, j'essaye de compiler une DLL Ingres.dll. Lors de la
compilation, j'ai bien un fichier Ingres.dll.manifest qui est créé,
dont voici le contenu :
<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1'
manifestVersion='1.0'>
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC80.CRT'
version='8.0.50608.0' processorArchitecture='x86'
publicKeyToken='1fc8b3b9a1e18e3b' />
</dependentAssembly>
</dependency>
</assembly>
Sur la machine cible, j'ai un répertoire
c:WindowsWinSxSx86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.050727.42_x-ww_0de06acd/
qui contient bien un msvcr80.dll (et deux autres DLL)
et il me dit toujours qu'il n'arrive pas à trouver msvcr80.dll
Bref, rien de changé par rapport à avant. Mais pourquoi est-ce que
ce crétin ne trouve pas la DLL ? Pourquoi est-ce que quand je la lui
fournit il n'arrive pas à l'utiliser. Pire : mais pourquoi ce con a
besoin de cette DLL pourrie ?
Peut-être suivre les conseils de microsoft : <http://msdn2.microsoft.com/en-US/library/ms235560(VS.80).aspx>
J'ai potassé, j'ai appliqué, mais ça ne marche toujours pas.
Pour rappel, j'essaye de compiler une DLL Ingres.dll. Lors de la compilation, j'ai bien un fichier Ingres.dll.manifest qui est créé, dont voici le contenu : <?xml version='1.0' encoding='UTF-8' standalone='yes'?> <assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'> <dependency> <dependentAssembly> <assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50608.0' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' /> </dependentAssembly> </dependency> </assembly>
Sur la machine cible, j'ai un répertoire c:WindowsWinSxSx86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.050727.42_x-ww_0de06acd/ qui contient bien un msvcr80.dll (et deux autres DLL) et il me dit toujours qu'il n'arrive pas à trouver msvcr80.dll
Bref, rien de changé par rapport à avant. Mais pourquoi est-ce que ce crétin ne trouve pas la DLL ? Pourquoi est-ce que quand je la lui fournit il n'arrive pas à l'utiliser. Pire : mais pourquoi ce con a besoin de cette DLL pourrie ?
Stephane Dupille
Jeuf écrit :
Salut Stéphane,
'lu
Je n'ai pas toutes les données de ton problème, mais il semble que .NET serait une bonne alternative... En utilisant "Perl for .NET", ça ne pourrait pas le faire ?
Non, pour deux raisons : 1/ ce n'est pas du .net que je veux faire, mais du Perl. Pire, ce que je veux c'est une appli Perl *portable*. Donc l'appli que j'ai développé avec mon BSD des familles doit pouvoir tourner sans *aucune* modification sur Windows.
Ce qui ma garantit la portabilité, c'est ActivePerl, et c'est celui que je compte utiliser. On notera pas ailleurs que Perl for .net se base sur ActivePerl, justement.
2/ Perl for .net ne contient pas non plus le module DBD::Ingres que je compte utiliser.
D'ailleurs, le problème que j'ai n'est pas un problème Perl, c'est juste que le compilo est trop exotique pour moi, la plateforme également, et que rien ne marche comme il le faudrait.
Comment on fait pour compiler une DLL ?
Jeuf <jfv@fr.fm> écrit :
Salut Stéphane,
'lu
Je n'ai pas toutes les données de ton problème, mais il semble que
.NET serait une bonne alternative...
En utilisant "Perl for .NET", ça ne pourrait pas le faire ?
Non, pour deux raisons :
1/ ce n'est pas du .net que je veux faire, mais du Perl. Pire, ce que
je veux c'est une appli Perl *portable*. Donc l'appli que j'ai
développé avec mon BSD des familles doit pouvoir tourner sans *aucune*
modification sur Windows.
Ce qui ma garantit la portabilité, c'est ActivePerl, et c'est celui
que je compte utiliser. On notera pas ailleurs que Perl for .net se
base sur ActivePerl, justement.
2/ Perl for .net ne contient pas non plus le module DBD::Ingres que je
compte utiliser.
D'ailleurs, le problème que j'ai n'est pas un problème Perl, c'est
juste que le compilo est trop exotique pour moi, la plateforme
également, et que rien ne marche comme il le faudrait.
Je n'ai pas toutes les données de ton problème, mais il semble que .NET serait une bonne alternative... En utilisant "Perl for .NET", ça ne pourrait pas le faire ?
Non, pour deux raisons : 1/ ce n'est pas du .net que je veux faire, mais du Perl. Pire, ce que je veux c'est une appli Perl *portable*. Donc l'appli que j'ai développé avec mon BSD des familles doit pouvoir tourner sans *aucune* modification sur Windows.
Ce qui ma garantit la portabilité, c'est ActivePerl, et c'est celui que je compte utiliser. On notera pas ailleurs que Perl for .net se base sur ActivePerl, justement.
2/ Perl for .net ne contient pas non plus le module DBD::Ingres que je compte utiliser.
D'ailleurs, le problème que j'ai n'est pas un problème Perl, c'est juste que le compilo est trop exotique pour moi, la plateforme également, et que rien ne marche comme il le faudrait.
Comment on fait pour compiler une DLL ?
Jacques Bratières
Le Tue, 31 Jul 2007 14:38:48 +0200, Stephane Dupille a écrit:
Jeuf écrit :
Salut Stéphane,
'lu
Je n'ai pas toutes les données de ton problème, mais il semble que .NET serait une bonne alternative... En utilisant "Perl for .NET", ça ne pourrait pas le faire ?
Non, pour deux raisons : 1/ ce n'est pas du .net que je veux faire, mais du Perl. Pire, ce que je veux c'est une appli Perl *portable*. Donc l'appli que j'ai développé avec mon BSD des familles doit pouvoir tourner sans *aucune* modification sur Windows.
Ce qui ma garantit la portabilité, c'est ActivePerl, et c'est celui que je compte utiliser. On notera pas ailleurs que Perl for .net se base sur ActivePerl, justement.
2/ Perl for .net ne contient pas non plus le module DBD::Ingres que je compte utiliser.
D'ailleurs, le problème que j'ai n'est pas un problème Perl, c'est juste que le compilo est trop exotique pour moi, la plateforme également, et que rien ne marche comme il le faudrait.
Comment on fait pour compiler une DLL ?
Et en utilisant les DBI:: ?
-- J.Bratières
Le Tue, 31 Jul 2007 14:38:48 +0200, Stephane Dupille
<sdupille@NOSPAM.fr.eu.org> a écrit:
Jeuf <jfv@fr.fm> écrit :
Salut Stéphane,
'lu
Je n'ai pas toutes les données de ton problème, mais il semble que
.NET serait une bonne alternative...
En utilisant "Perl for .NET", ça ne pourrait pas le faire ?
Non, pour deux raisons :
1/ ce n'est pas du .net que je veux faire, mais du Perl. Pire, ce que
je veux c'est une appli Perl *portable*. Donc l'appli que j'ai
développé avec mon BSD des familles doit pouvoir tourner sans *aucune*
modification sur Windows.
Ce qui ma garantit la portabilité, c'est ActivePerl, et c'est celui
que je compte utiliser. On notera pas ailleurs que Perl for .net se
base sur ActivePerl, justement.
2/ Perl for .net ne contient pas non plus le module DBD::Ingres que je
compte utiliser.
D'ailleurs, le problème que j'ai n'est pas un problème Perl, c'est
juste que le compilo est trop exotique pour moi, la plateforme
également, et que rien ne marche comme il le faudrait.
Le Tue, 31 Jul 2007 14:38:48 +0200, Stephane Dupille a écrit:
Jeuf écrit :
Salut Stéphane,
'lu
Je n'ai pas toutes les données de ton problème, mais il semble que .NET serait une bonne alternative... En utilisant "Perl for .NET", ça ne pourrait pas le faire ?
Non, pour deux raisons : 1/ ce n'est pas du .net que je veux faire, mais du Perl. Pire, ce que je veux c'est une appli Perl *portable*. Donc l'appli que j'ai développé avec mon BSD des familles doit pouvoir tourner sans *aucune* modification sur Windows.
Ce qui ma garantit la portabilité, c'est ActivePerl, et c'est celui que je compte utiliser. On notera pas ailleurs que Perl for .net se base sur ActivePerl, justement.
2/ Perl for .net ne contient pas non plus le module DBD::Ingres que je compte utiliser.
D'ailleurs, le problème que j'ai n'est pas un problème Perl, c'est juste que le compilo est trop exotique pour moi, la plateforme également, et que rien ne marche comme il le faudrait.
Comment on fait pour compiler une DLL ?
Et en utilisant les DBI:: ?
-- J.Bratières
Stephane Dupille
Jacques Bratières écrit :
Et en utilisant les DBI:: ?
Ben justement, pour pouvoir utiliser les DBI, j'ai besoin du driver qui va bien. Le driver qui va bien avec ma base Ingres, c'est DBD::Ingres, c'est justement DBD::Ingres que je n'arrive pas à compiler. Enfin, plus précisemment, la DLL se compile bien, et j'arrive à l'utiliser sur ma machine de Dev, mais je n'arrive pas à la déployer sur le Win XP d'à côté pour cause de DLL manquante mais qui y est quand même.
Déployer l'environnement de Dev sur les machines en prod pour faire marcher une pauvre DLL de 50 Ko n'est pas une option.
Jacques Bratières <j.bra.t@on.invalid.fr> écrit :
Et en utilisant les DBI:: ?
Ben justement, pour pouvoir utiliser les DBI, j'ai besoin du driver
qui va bien. Le driver qui va bien avec ma base Ingres, c'est
DBD::Ingres, c'est justement DBD::Ingres que je n'arrive pas à
compiler. Enfin, plus précisemment, la DLL se compile bien, et
j'arrive à l'utiliser sur ma machine de Dev, mais je n'arrive pas à la
déployer sur le Win XP d'à côté pour cause de DLL manquante mais qui y
est quand même.
Déployer l'environnement de Dev sur les machines en prod pour faire
marcher une pauvre DLL de 50 Ko n'est pas une option.
Ben justement, pour pouvoir utiliser les DBI, j'ai besoin du driver qui va bien. Le driver qui va bien avec ma base Ingres, c'est DBD::Ingres, c'est justement DBD::Ingres que je n'arrive pas à compiler. Enfin, plus précisemment, la DLL se compile bien, et j'arrive à l'utiliser sur ma machine de Dev, mais je n'arrive pas à la déployer sur le Win XP d'à côté pour cause de DLL manquante mais qui y est quand même.
Déployer l'environnement de Dev sur les machines en prod pour faire marcher une pauvre DLL de 50 Ko n'est pas une option.
Thierry
"Stephane Dupille" a écrit dans le message de news:
Déployer l'environnement de Dev sur les machines en prod pour faire marcher une pauvre DLL de 50 Ko n'est pas une option.
Plusieurs options: - Vois du cote des manifestes et la KB deja citée - installe le .Net qui va bien. - utilise un compilo plus ancien (je n'ai eu ce genre de probleme qu'avec VC2005, mais je n'en suis pas a la phase deploiement).
Dans tous les cas -> fr.comp.os.ms-windows.programmation
"Stephane Dupille" <sdupille@NOSPAM.fr.eu.org> a écrit dans le message de
news: ygetzrkvin7.fsf@nospam.fr.eu.org...
Déployer l'environnement de Dev sur les machines en prod pour faire
marcher une pauvre DLL de 50 Ko n'est pas une option.
Plusieurs options:
- Vois du cote des manifestes et la KB deja citée
- installe le .Net qui va bien.
- utilise un compilo plus ancien (je n'ai eu ce genre de probleme qu'avec
VC2005, mais je n'en suis pas a la phase deploiement).
Dans tous les cas -> fr.comp.os.ms-windows.programmation
"Stephane Dupille" a écrit dans le message de news:
Déployer l'environnement de Dev sur les machines en prod pour faire marcher une pauvre DLL de 50 Ko n'est pas une option.
Plusieurs options: - Vois du cote des manifestes et la KB deja citée - installe le .Net qui va bien. - utilise un compilo plus ancien (je n'ai eu ce genre de probleme qu'avec VC2005, mais je n'en suis pas a la phase deploiement).
Dans tous les cas -> fr.comp.os.ms-windows.programmation
Thierry
"Stephane Dupille" a écrit dans le message de news:
Déployer l'environnement de Dev sur les machines en prod pour faire marcher une pauvre DLL de 50 Ko n'est pas une option.
Plusieurs options: - Vois du cote des manifestes et la KB deja citée - installe le .Net qui va bien. - utilise un compilo plus ancien (je n'ai eu ce genre de probleme qu'avec VC2005, mais je n'en suis pas a la phase deploiement).
Dans tous les cas -> fr.comp.os.ms-windows.programmation
"Stephane Dupille" <sdupille@NOSPAM.fr.eu.org> a écrit dans le message de
news: ygetzrkvin7.fsf@nospam.fr.eu.org...
Déployer l'environnement de Dev sur les machines en prod pour faire
marcher une pauvre DLL de 50 Ko n'est pas une option.
Plusieurs options:
- Vois du cote des manifestes et la KB deja citée
- installe le .Net qui va bien.
- utilise un compilo plus ancien (je n'ai eu ce genre de probleme qu'avec
VC2005, mais je n'en suis pas a la phase deploiement).
Dans tous les cas -> fr.comp.os.ms-windows.programmation
"Stephane Dupille" a écrit dans le message de news:
Déployer l'environnement de Dev sur les machines en prod pour faire marcher une pauvre DLL de 50 Ko n'est pas une option.
Plusieurs options: - Vois du cote des manifestes et la KB deja citée - installe le .Net qui va bien. - utilise un compilo plus ancien (je n'ai eu ce genre de probleme qu'avec VC2005, mais je n'en suis pas a la phase deploiement).
Dans tous les cas -> fr.comp.os.ms-windows.programmation
kduc
Stephane Dupille a écrit :
Jacques Bratières écrit :
Et en utilisant les DBI:: ?
Ben justement, pour pouvoir utiliser les DBI, j'ai besoin du driver qui va bien. Le driver qui va bien avec ma base Ingres, c'est DBD::Ingres, c'est justement DBD::Ingres que je n'arrive pas à compiler. Enfin, plus précisemment, la DLL se compile bien, et j'arrive à l'utiliser sur ma machine de Dev, mais je n'arrive pas à la déployer sur le Win XP d'à côté pour cause de DLL manquante mais qui y est quand même.
Déployer l'environnement de Dev sur les machines en prod pour faire marcher une pauvre DLL de 50 Ko n'est pas une option.
Ben justement, pour pouvoir utiliser les DBI, j'ai besoin du driver
qui va bien. Le driver qui va bien avec ma base Ingres, c'est
DBD::Ingres, c'est justement DBD::Ingres que je n'arrive pas à
compiler. Enfin, plus précisemment, la DLL se compile bien, et
j'arrive à l'utiliser sur ma machine de Dev, mais je n'arrive pas à la
déployer sur le Win XP d'à côté pour cause de DLL manquante mais qui y
est quand même.
Déployer l'environnement de Dev sur les machines en prod pour faire
marcher une pauvre DLL de 50 Ko n'est pas une option.
Ben justement, pour pouvoir utiliser les DBI, j'ai besoin du driver qui va bien. Le driver qui va bien avec ma base Ingres, c'est DBD::Ingres, c'est justement DBD::Ingres que je n'arrive pas à compiler. Enfin, plus précisemment, la DLL se compile bien, et j'arrive à l'utiliser sur ma machine de Dev, mais je n'arrive pas à la déployer sur le Win XP d'à côté pour cause de DLL manquante mais qui y est quand même.
Déployer l'environnement de Dev sur les machines en prod pour faire marcher une pauvre DLL de 50 Ko n'est pas une option.
Non, c'est pas la bonne méthode. Le systeme doit charger la bonne (version de) DLL en fonction du manifeste du prog. C'etait au depart censé resoudre les pb de "DLL Hell"
"kduc" <kduc@neuf.fr> a écrit dans le message de news:
f8nbqn$nsu$1@talisker.lacave.net...
Non, c'est pas la bonne méthode.
Le systeme doit charger la bonne (version de) DLL en fonction du manifeste
du prog.
C'etait au depart censé resoudre les pb de "DLL Hell"
Non, c'est pas la bonne méthode. Le systeme doit charger la bonne (version de) DLL en fonction du manifeste du prog. C'etait au depart censé resoudre les pb de "DLL Hell"
Stephane Dupille
kduc écrit :
Avez-vous essayé de mettre le chemin : c:WindowsWinSxSx86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.050727.42_x-ww_0de06acd dans le PATH de la machine d'à côté ?
Oui, j'ai essayé, avec exactement le même résultat que quand je copiait la DLL pour la mettre dans le répertoire qui contient ma propre DLL : il n'arrive pas à l'utiliser proprement.
kduc <kduc@neuf.fr> écrit :
Avez-vous essayé de mettre le chemin :
c:WindowsWinSxSx86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.050727.42_x-ww_0de06acd
dans le PATH de la machine d'à côté ?
Oui, j'ai essayé, avec exactement le même résultat que quand je
copiait la DLL pour la mettre dans le répertoire qui contient ma
propre DLL : il n'arrive pas à l'utiliser proprement.
Avez-vous essayé de mettre le chemin : c:WindowsWinSxSx86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.050727.42_x-ww_0de06acd dans le PATH de la machine d'à côté ?
Oui, j'ai essayé, avec exactement le même résultat que quand je copiait la DLL pour la mettre dans le répertoire qui contient ma propre DLL : il n'arrive pas à l'utiliser proprement.
