Hello,
J'ai compilé un soft avec VC++ 2003, et il est lié aux dll msvcp71.dll et
msvcr71.dll. J'ai cherché sur le site à MS ces dll sous forme de
redistribuable, mais j'ai rien trouvé. Apparement, MS ne les fourni qu'avec
le framework .Net.
Donc je les file directement comme ça avec mon appli sans les installer dans
system32.
Comment procédez-vous pour refiler ces dll et si vous les mettez dans
system32 peut-on gérer ça avec InnoSetup ?
Merci.
Si, mais il peut faire du C++ managé *et* du C++ natif "classique".
Ah bon j'étais persuadé du contraire. Je suis surpris je ne me serais pas attendu à ça de la part de crosoft.
-- Arnaud
Pour me répondre cliquer ici http://www.cerbermail.com/?rXioF2RWNX
Arnaud Debaene
BOUTRY Arnaud wrote:
Arnaud Debaene a pensé très fort :
Si, mais il peut faire du C++ managé *et* du C++ natif "classique".
Ah bon j'étais persuadé du contraire. Je suis surpris je ne me serais pas attendu à ça de la part de crosoft.
Ah? Pourquoi? Si tu t'imagines que MS veut totalement abandonner le C++ classique, commences par te demander en quoi sont écrits et avec quoi sont compilés Windows, Office, etc....
Arnaud
BOUTRY Arnaud wrote:
Arnaud Debaene a pensé très fort :
Si, mais il peut faire du C++ managé *et* du C++ natif "classique".
Ah bon j'étais persuadé du contraire. Je suis surpris je ne me serais
pas attendu à ça de la part de crosoft.
Ah? Pourquoi? Si tu t'imagines que MS veut totalement abandonner le C++
classique, commences par te demander en quoi sont écrits et avec quoi sont
compilés Windows, Office, etc....
Si, mais il peut faire du C++ managé *et* du C++ natif "classique".
Ah bon j'étais persuadé du contraire. Je suis surpris je ne me serais pas attendu à ça de la part de crosoft.
Ah? Pourquoi? Si tu t'imagines que MS veut totalement abandonner le C++ classique, commences par te demander en quoi sont écrits et avec quoi sont compilés Windows, Office, etc....
Arnaud
Quentin Pouplard
Arnaud Debaene wrote:
Ah? Pourquoi? Si tu t'imagines que MS veut totalement abandonner le C++ classique, commences par te demander en quoi sont écrits et avec quoi sont compilés Windows, Office, etc....
Ah? Pourquoi? Si tu t'imagines que MS veut totalement abandonner le
C++
classique, commences par te demander en quoi sont écrits et avec quoi
sont compilés Windows, Office, etc....
Ah? Pourquoi? Si tu t'imagines que MS veut totalement abandonner le C++ classique, commences par te demander en quoi sont écrits et avec quoi sont compilés Windows, Office, etc....
> Tu devrais avoir des fichiers VC_User_CRT71_RTL_X86_---.msm et VC_User_STL71_RTL_X86_---.msm sur ton disque (chez moi, c'est dans c:program filescommon filesmerge modules). Ce sont des merge modules que tu peux intégrer dans un MSI pour redistribuer les DLL en question.
Je le savais pas. Merci pour l'info.
> Donc je les file directement comme ça avec mon appli sans les installer
dans
> system32. C'est la nouvelle politique recommandée par MS pour éviter le "DLL Hell" : installer systématiquement les DLLs dans le répertoire de l'appli, sauf pour les assemblies .NET signés que l'on peut mettre dans le GAC. Je ne suis pas trop certain de savoir si c'est une bonne idée ou pas (c'est en tout cas certainement mauvais pour l'espace disque, mais quand on sait qu'il y a bien eu 3 ou 4 versions différentes de msvcp60.dll, c'est peut être une bonne idée...). Par ailleurs, installer ces DLLs dans le répertoire de l'appli peut permetttre à des utilisateurs aux droits restreints d'utiliser ton setup.
Exact. C'est pourquoi je ne veux pas les refiler moi mais souhaite un espèce d'installeur de runtime à la VB.
> Comment procédez-vous pour refiler ces dll et si vous les mettez dans > system32 peut-on gérer ça avec InnoSetup ? Je ne connais pas InnoSetup, mais s'il gère MSI tu peux utiliser les merges modules que je t'ai indiqué ci-dessus. Sion, les projets de déploiement de VS2003 font généralement ca très bien, tant que le setup reste raisonnablement simple. Arnaud
Merci. A+
Aurélien
> Tu devrais avoir des fichiers VC_User_CRT71_RTL_X86_---.msm et
VC_User_STL71_RTL_X86_---.msm sur ton disque (chez moi, c'est dans
c:program filescommon filesmerge modules). Ce sont des merge
modules que tu peux intégrer dans un MSI pour redistribuer les DLL en
question.
Je le savais pas. Merci pour l'info.
> Donc je les file directement comme ça avec mon appli sans les installer
dans
> system32.
C'est la nouvelle politique recommandée par MS pour éviter le "DLL
Hell" : installer systématiquement les DLLs dans le répertoire de
l'appli, sauf pour les assemblies .NET signés que l'on peut mettre
dans le GAC.
Je ne suis pas trop certain de savoir si c'est une bonne idée ou pas
(c'est en tout cas certainement mauvais pour l'espace disque, mais
quand on sait qu'il y a bien eu 3 ou 4 versions différentes de
msvcp60.dll, c'est peut être une bonne idée...). Par ailleurs,
installer ces DLLs dans le répertoire de l'appli peut permetttre à des
utilisateurs aux droits restreints d'utiliser ton setup.
Exact. C'est pourquoi je ne veux pas les refiler moi mais souhaite un espèce
d'installeur de runtime à la VB.
> Comment procédez-vous pour refiler ces dll et si vous les mettez dans
> system32 peut-on gérer ça avec InnoSetup ?
Je ne connais pas InnoSetup, mais s'il gère MSI tu peux utiliser les
merges modules que je t'ai indiqué ci-dessus. Sion, les projets de
déploiement de VS2003 font généralement ca très bien, tant que le
setup reste raisonnablement simple.
Arnaud
> Tu devrais avoir des fichiers VC_User_CRT71_RTL_X86_---.msm et VC_User_STL71_RTL_X86_---.msm sur ton disque (chez moi, c'est dans c:program filescommon filesmerge modules). Ce sont des merge modules que tu peux intégrer dans un MSI pour redistribuer les DLL en question.
Je le savais pas. Merci pour l'info.
> Donc je les file directement comme ça avec mon appli sans les installer
dans
> system32. C'est la nouvelle politique recommandée par MS pour éviter le "DLL Hell" : installer systématiquement les DLLs dans le répertoire de l'appli, sauf pour les assemblies .NET signés que l'on peut mettre dans le GAC. Je ne suis pas trop certain de savoir si c'est une bonne idée ou pas (c'est en tout cas certainement mauvais pour l'espace disque, mais quand on sait qu'il y a bien eu 3 ou 4 versions différentes de msvcp60.dll, c'est peut être une bonne idée...). Par ailleurs, installer ces DLLs dans le répertoire de l'appli peut permetttre à des utilisateurs aux droits restreints d'utiliser ton setup.
Exact. C'est pourquoi je ne veux pas les refiler moi mais souhaite un espèce d'installeur de runtime à la VB.
> Comment procédez-vous pour refiler ces dll et si vous les mettez dans > system32 peut-on gérer ça avec InnoSetup ? Je ne connais pas InnoSetup, mais s'il gère MSI tu peux utiliser les merges modules que je t'ai indiqué ci-dessus. Sion, les projets de déploiement de VS2003 font généralement ca très bien, tant que le setup reste raisonnablement simple. Arnaud
Merci. A+
Aurélien
BOUTRY Arnaud
Arnaud Debaene avait soumis l'idée :
Ah? Pourquoi? Si tu t'imagines que MS veut totalement abandonner le C++ classique, commences par te demander en quoi sont écrits et avec quoi sont compilés Windows, Office, etc....
Il s'agit pas d'abandonner le C++ mais de forcer les développeurs à laisser tomber Win32 pour passer à .net
-- Arnaud
Pour me répondre cliquer ici http://www.cerbermail.com/?rXioF2RWNX
Arnaud Debaene avait soumis l'idée :
Ah? Pourquoi? Si tu t'imagines que MS veut totalement abandonner le C++
classique, commences par te demander en quoi sont écrits et avec quoi sont
compilés Windows, Office, etc....
Il s'agit pas d'abandonner le C++ mais de forcer les développeurs à
laisser tomber Win32 pour passer à .net
--
Arnaud
Pour me répondre cliquer ici
http://www.cerbermail.com/?rXioF2RWNX
Ah? Pourquoi? Si tu t'imagines que MS veut totalement abandonner le C++ classique, commences par te demander en quoi sont écrits et avec quoi sont compilés Windows, Office, etc....
Il s'agit pas d'abandonner le C++ mais de forcer les développeurs à laisser tomber Win32 pour passer à .net
-- Arnaud
Pour me répondre cliquer ici http://www.cerbermail.com/?rXioF2RWNX
