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.
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.
De toute façon VC++ 2003 ne fait que du .net tu as donc bersoin du framework .net sur les machines ou tu déploies ton appli donc tu devrais y trouver ces dll.
-- Arnaud
Pour me répondre cliquer ici http://www.cerbermail.com/?rXioF2RWNX
Aurélien Regat-Barrel avait énoncé :
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.
De toute façon VC++ 2003 ne fait que du .net tu as donc bersoin du
framework .net sur les machines ou tu déploies ton appli donc tu
devrais y trouver ces dll.
--
Arnaud
Pour me répondre cliquer ici
http://www.cerbermail.com/?rXioF2RWNX
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.
De toute façon VC++ 2003 ne fait que du .net tu as donc bersoin du framework .net sur les machines ou tu déploies ton appli donc tu devrais y trouver ces dll.
-- Arnaud
Pour me répondre cliquer ici http://www.cerbermail.com/?rXioF2RWNX
Thierry
Bonjour,
Aurélien Regat-Barrel a écrit :
J'ai compilé un soft avec VC++ 2003, et il est lié aux dll msvcp71.dll et msvcr71.dll.
Par curiosité : elle font quelle taille ces DLL ?
-- « Willy, j'ai mangé le chat. »
Bonjour,
Aurélien Regat-Barrel a écrit :
J'ai compilé un soft avec VC++ 2003, et il est lié aux dll msvcp71.dll
et msvcr71.dll.
J'ai compilé un soft avec VC++ 2003, et il est lié aux dll msvcp71.dll et msvcr71.dll.
Par curiosité : elle font quelle taille ces DLL ?
-- « Willy, j'ai mangé le chat. »
Remi Thomas
> De toute façon VC++ 2003 ne fait que du .net tu as donc bersoin du framework .net sur les machines ou tu déploies ton appli donc tu devrais y trouver ces dll.
C'est nouveau cela. Non, Visual Studio .NET 2003 et VC++ 2003 ne font pas que du .NET Vous pouvez toujours faire le type de projet que l'on à dans VC++ 6 (Console, Win32, MFC, ATL) et en plus des projet managé .NET. Bien entendu un "hello world" en mode console ou Win32 ne demande aucun déploiement. Les applications MFC ou ATL demandent le même type de déploiement qu'en VC6.
Rémi
-- Rémi Thomas - MVP Visual Studio .NET Développeur Windows indépendant http://www.xtware.com/cv
>
De toute façon VC++ 2003 ne fait que du .net tu as donc bersoin du
framework .net sur les machines ou tu déploies ton appli donc tu
devrais y trouver ces dll.
C'est nouveau cela.
Non, Visual Studio .NET 2003 et VC++ 2003 ne font pas que du .NET
Vous pouvez toujours faire le type de projet que l'on à dans VC++ 6
(Console, Win32, MFC, ATL) et en plus des projet managé .NET.
Bien entendu un "hello world" en mode console ou Win32 ne demande aucun
déploiement.
Les applications MFC ou ATL demandent le même type de déploiement qu'en VC6.
Rémi
--
Rémi Thomas - MVP Visual Studio .NET
Développeur Windows indépendant
http://www.xtware.com/cv
> De toute façon VC++ 2003 ne fait que du .net tu as donc bersoin du framework .net sur les machines ou tu déploies ton appli donc tu devrais y trouver ces dll.
C'est nouveau cela. Non, Visual Studio .NET 2003 et VC++ 2003 ne font pas que du .NET Vous pouvez toujours faire le type de projet que l'on à dans VC++ 6 (Console, Win32, MFC, ATL) et en plus des projet managé .NET. Bien entendu un "hello world" en mode console ou Win32 ne demande aucun déploiement. Les applications MFC ou ATL demandent le même type de déploiement qu'en VC6.
Rémi
-- Rémi Thomas - MVP Visual Studio .NET Développeur Windows indépendant http://www.xtware.com/cv
Aurelien REGAT-BARREL
BOUTRY Arnaud wrote:
De toute façon VC++ 2003 ne fait que du .net tu as donc bersoin du framework .net sur les machines ou tu déploies ton appli donc tu devrais y trouver ces dll.
Je confirme je suis en Win32, et j'ai déployé mon soft sur plusieurs postes sans pblm, aucun n'a .Net.
-- Aurélien (Je recherche un stage!)
BOUTRY Arnaud wrote:
De toute façon VC++ 2003 ne fait que du .net tu as donc bersoin du
framework .net sur les machines ou tu déploies ton appli donc tu
devrais y trouver ces dll.
Je confirme je suis en Win32, et j'ai déployé mon soft sur plusieurs postes
sans pblm, aucun n'a .Net.
De toute façon VC++ 2003 ne fait que du .net tu as donc bersoin du framework .net sur les machines ou tu déploies ton appli donc tu devrais y trouver ces dll.
Je confirme je suis en Win32, et j'ai déployé mon soft sur plusieurs postes sans pblm, aucun n'a .Net.
-- Aurélien (Je recherche un stage!)
Aurelien REGAT-BARREL
Thierry wrote:
Par curiosité : elle font quelle taille ces DLL ?
msvcr71.dll : 340 Ko msvcp71.dll : 488 Ko
C'est pas un probleme de taille. Je pense que ces dll devraient être misent dans system32. Je suis étonné que MS ne fournisse pas un truc de resditribuable comme pour les anciens VB. J'hésite à compiler en statique, mais comme j'ai VTK à recompiler et que le bébé nécessite plusieurs heures sur ma bécanne, ben je cherche une alternative. Surtout qu'en statique, si je me trompe pas, ça va augmenter la taille de mes dll de plus de 800Ko. J'ai une quizaine de dll...
-- Aurélien (Je recherche un stage!)
Thierry wrote:
Par curiosité : elle font quelle taille ces DLL ?
msvcr71.dll : 340 Ko
msvcp71.dll : 488 Ko
C'est pas un probleme de taille. Je pense que ces dll devraient être misent
dans system32. Je suis étonné que MS ne fournisse pas un truc de
resditribuable comme pour les anciens VB.
J'hésite à compiler en statique, mais comme j'ai VTK à recompiler et que le
bébé nécessite plusieurs heures sur ma bécanne, ben je cherche une
alternative. Surtout qu'en statique, si je me trompe pas, ça va augmenter
la taille de mes dll de plus de 800Ko. J'ai une quizaine de dll...
C'est pas un probleme de taille. Je pense que ces dll devraient être misent dans system32. Je suis étonné que MS ne fournisse pas un truc de resditribuable comme pour les anciens VB. J'hésite à compiler en statique, mais comme j'ai VTK à recompiler et que le bébé nécessite plusieurs heures sur ma bécanne, ben je cherche une alternative. Surtout qu'en statique, si je me trompe pas, ça va augmenter la taille de mes dll de plus de 800Ko. J'ai une quizaine de dll...
-- Aurélien (Je recherche un stage!)
Jean-Claude
Bonjour, Je suis dans la même situation. J'ai pris des projets VC6 +MFC qui utilisait mfc42.dll...en le recompilant avec ".net 2003", mes projets ont besoin de mfc71.dll+mfc71fra.dll+msvcr71.dll .... ces dll ne sont pas toujours installées sur les OS. Tu dois donc les installer chez les clients pour être sûr. Je trouve que le meilleur moyen est de mettre ces dlls dans dans le même répertoire que l'application. On est au moins sûr que ce seront celles-ci qui seront utilisées. En les mettant dans le rép. /system32/, ça fonctionne aussi jusqu'à ce qu'un nouveau programme installé les remplace par des dlls de même nom mais pas toujours de même version (ça ne devrait pas mais il peut y avoir des incompatibilités...)
Bonjour,
Je suis dans la même situation.
J'ai pris des projets VC6 +MFC qui utilisait mfc42.dll...en le recompilant
avec ".net 2003", mes projets ont besoin de
mfc71.dll+mfc71fra.dll+msvcr71.dll .... ces dll ne sont pas toujours
installées sur les OS. Tu dois donc les installer chez les clients pour être
sûr. Je trouve que le meilleur moyen est de mettre ces dlls dans dans le
même répertoire que l'application. On est au moins sûr que ce seront
celles-ci qui seront utilisées. En les mettant dans le rép. /system32/, ça
fonctionne aussi jusqu'à ce qu'un nouveau programme installé les remplace
par des dlls de même nom mais pas toujours de même version (ça ne devrait
pas mais il peut y avoir des incompatibilités...)
Bonjour, Je suis dans la même situation. J'ai pris des projets VC6 +MFC qui utilisait mfc42.dll...en le recompilant avec ".net 2003", mes projets ont besoin de mfc71.dll+mfc71fra.dll+msvcr71.dll .... ces dll ne sont pas toujours installées sur les OS. Tu dois donc les installer chez les clients pour être sûr. Je trouve que le meilleur moyen est de mettre ces dlls dans dans le même répertoire que l'application. On est au moins sûr que ce seront celles-ci qui seront utilisées. En les mettant dans le rép. /system32/, ça fonctionne aussi jusqu'à ce qu'un nouveau programme installé les remplace par des dlls de même nom mais pas toujours de même version (ça ne devrait pas mais il peut y avoir des incompatibilités...)
Aurélien Regat-Barrel
Bonjour, Je vais me résigner à ça alors. Je trouve cela regrettable, car ces dll sont comparables à dees dll système à mes yeux. C'est vraiment la base de tout programme C++. Mais bon, en même temps, c'est pas un soft pro que je fais, ça restera sur quelques ordis en interne, c'est pas grave. Merci.
"Jean-Claude" a écrit dans le message de news: 401901b3$
Bonjour, Je suis dans la même situation. J'ai pris des projets VC6 +MFC qui utilisait mfc42.dll...en le recompilant avec ".net 2003", mes projets ont besoin de mfc71.dll+mfc71fra.dll+msvcr71.dll .... ces dll ne sont pas toujours installées sur les OS. Tu dois donc les installer chez les clients pour
être
sûr. Je trouve que le meilleur moyen est de mettre ces dlls dans dans le même répertoire que l'application. On est au moins sûr que ce seront celles-ci qui seront utilisées. En les mettant dans le rép. /system32/, ça fonctionne aussi jusqu'à ce qu'un nouveau programme installé les remplace par des dlls de même nom mais pas toujours de même version (ça ne devrait pas mais il peut y avoir des incompatibilités...)
Bonjour,
Je vais me résigner à ça alors. Je trouve cela regrettable, car ces dll sont
comparables à dees dll système à mes yeux. C'est vraiment la base de tout
programme C++.
Mais bon, en même temps, c'est pas un soft pro que je fais, ça restera sur
quelques ordis en interne, c'est pas grave.
Merci.
"Jean-Claude" <antispam@toto.ch> a écrit dans le message de news:
401901b3$1_1@news.tiscalinet.ch...
Bonjour,
Je suis dans la même situation.
J'ai pris des projets VC6 +MFC qui utilisait mfc42.dll...en le recompilant
avec ".net 2003", mes projets ont besoin de
mfc71.dll+mfc71fra.dll+msvcr71.dll .... ces dll ne sont pas toujours
installées sur les OS. Tu dois donc les installer chez les clients pour
être
sûr. Je trouve que le meilleur moyen est de mettre ces dlls dans dans le
même répertoire que l'application. On est au moins sûr que ce seront
celles-ci qui seront utilisées. En les mettant dans le rép. /system32/, ça
fonctionne aussi jusqu'à ce qu'un nouveau programme installé les remplace
par des dlls de même nom mais pas toujours de même version (ça ne devrait
pas mais il peut y avoir des incompatibilités...)
Bonjour, Je vais me résigner à ça alors. Je trouve cela regrettable, car ces dll sont comparables à dees dll système à mes yeux. C'est vraiment la base de tout programme C++. Mais bon, en même temps, c'est pas un soft pro que je fais, ça restera sur quelques ordis en interne, c'est pas grave. Merci.
"Jean-Claude" a écrit dans le message de news: 401901b3$
Bonjour, Je suis dans la même situation. J'ai pris des projets VC6 +MFC qui utilisait mfc42.dll...en le recompilant avec ".net 2003", mes projets ont besoin de mfc71.dll+mfc71fra.dll+msvcr71.dll .... ces dll ne sont pas toujours installées sur les OS. Tu dois donc les installer chez les clients pour
être
sûr. Je trouve que le meilleur moyen est de mettre ces dlls dans dans le même répertoire que l'application. On est au moins sûr que ce seront celles-ci qui seront utilisées. En les mettant dans le rép. /system32/, ça fonctionne aussi jusqu'à ce qu'un nouveau programme installé les remplace par des dlls de même nom mais pas toujours de même version (ça ne devrait pas mais il peut y avoir des incompatibilités...)
adebaene
"Aurélien Regat-Barrel" wrote in message news:<4018582a$0$19290$...
Hello, J'ai compilé un soft avec VC++ 2003, et il est lié aux dll msvcp71.dll et msvcr71.dll.
Oui, ce sont la CRT et la SL sous forme DLL. Tu peux t'en passer si tu linkes statiquement ton appli avec la CRT (option de compilation /ML ou /MLd ou /MT ou /MTd selon ce que tu veux exactement)
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.
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.
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.
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
"Aurélien Regat-Barrel" <nospam@nospam.com> wrote in message news:<4018582a$0$19290$626a54ce@news.free.fr>...
Hello,
J'ai compilé un soft avec VC++ 2003, et il est lié aux dll msvcp71.dll et
msvcr71.dll.
Oui, ce sont la CRT et la SL sous forme DLL. Tu peux t'en passer si tu
linkes statiquement ton appli avec la CRT (option de compilation /ML
ou /MLd ou /MT ou /MTd selon ce que tu veux exactement)
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.
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.
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.
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.
"Aurélien Regat-Barrel" wrote in message news:<4018582a$0$19290$...
Hello, J'ai compilé un soft avec VC++ 2003, et il est lié aux dll msvcp71.dll et msvcr71.dll.
Oui, ce sont la CRT et la SL sous forme DLL. Tu peux t'en passer si tu linkes statiquement ton appli avec la CRT (option de compilation /ML ou /MLd ou /MT ou /MTd selon ce que tu veux exactement)
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.
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.
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.
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
Remi Thomas
Aurélien Regat-Barrel wrote:
Bonjour, Je vais me résigner à ça alors. Je trouve cela regrettable, car ces dll sont comparables à dees dll système à mes yeux. C'est vraiment la base de tout programme C++. Mais bon, en même temps, c'est pas un soft pro que je fais, ça restera sur quelques ordis en interne, c'est pas grave. Merci.
Sur votre projet Properties->General->Use of MFC vous choisissez "Use MFC in a Static Library" et vous obtenez un exe qui ne dépand plus de rien du tout. Il est plus gros mais cela reste très raisonnable (environ 500 Ko).
Rémi
-- Rémi Thomas - MVP Visual Studio .NET Développeur Windows indépendant http://www.xtware.com/cv
Aurélien Regat-Barrel wrote:
Bonjour,
Je vais me résigner à ça alors. Je trouve cela regrettable, car ces
dll sont comparables à dees dll système à mes yeux. C'est vraiment la
base de tout programme C++.
Mais bon, en même temps, c'est pas un soft pro que je fais, ça
restera sur quelques ordis en interne, c'est pas grave.
Merci.
Sur votre projet Properties->General->Use of MFC vous choisissez "Use MFC in
a Static Library" et vous obtenez un exe qui ne dépand plus de rien du tout.
Il est plus gros mais cela reste très raisonnable (environ 500 Ko).
Rémi
--
Rémi Thomas - MVP Visual Studio .NET
Développeur Windows indépendant
http://www.xtware.com/cv
Bonjour, Je vais me résigner à ça alors. Je trouve cela regrettable, car ces dll sont comparables à dees dll système à mes yeux. C'est vraiment la base de tout programme C++. Mais bon, en même temps, c'est pas un soft pro que je fais, ça restera sur quelques ordis en interne, c'est pas grave. Merci.
Sur votre projet Properties->General->Use of MFC vous choisissez "Use MFC in a Static Library" et vous obtenez un exe qui ne dépand plus de rien du tout. Il est plus gros mais cela reste très raisonnable (environ 500 Ko).
Rémi
-- Rémi Thomas - MVP Visual Studio .NET Développeur Windows indépendant http://www.xtware.com/cv
BOUTRY Arnaud
Aurelien REGAT-BARREL avait énoncé :
BOUTRY Arnaud wrote:
De toute façon VC++ 2003 ne fait que du .net tu as donc bersoin du framework .net sur les machines ou tu déploies ton appli donc tu devrais y trouver ces dll.
Je confirme je suis en Win32, et j'ai déployé mon soft sur plusieurs postes sans pblm, aucun n'a .Net.
Ok d'accord j'ai rien dit je dois confondre VS 2003 c'est pas VS .net??
-- Arnaud
Pour me répondre cliquer ici http://www.cerbermail.com/?rXioF2RWNX
Aurelien REGAT-BARREL avait énoncé :
BOUTRY Arnaud wrote:
De toute façon VC++ 2003 ne fait que du .net tu as donc bersoin du
framework .net sur les machines ou tu déploies ton appli donc tu
devrais y trouver ces dll.
Je confirme je suis en Win32, et j'ai déployé mon soft sur plusieurs postes
sans pblm, aucun n'a .Net.
Ok d'accord j'ai rien dit je dois confondre
VS 2003 c'est pas VS .net??
--
Arnaud
Pour me répondre cliquer ici
http://www.cerbermail.com/?rXioF2RWNX
De toute façon VC++ 2003 ne fait que du .net tu as donc bersoin du framework .net sur les machines ou tu déploies ton appli donc tu devrais y trouver ces dll.
Je confirme je suis en Win32, et j'ai déployé mon soft sur plusieurs postes sans pblm, aucun n'a .Net.
Ok d'accord j'ai rien dit je dois confondre VS 2003 c'est pas VS .net??
-- Arnaud
Pour me répondre cliquer ici http://www.cerbermail.com/?rXioF2RWNX
