Discussion :

[vdaanen]

Bonjour a tous,

Actuellement, je developpe des applis liées statiquement a la CRT (/MT[d] pour les connaisseurs). Je fais ça pour des raisons historiques (wrt la société et une autre société soeur..)

Toutefois, ce choix nous pose des soucis d'évolution et on envisage de lier les applis dynamiquement a la CRT (/MD[d]). Je me suis renseigné pour connaitre les raisons du choix initial de /MT et on m'a répondu que les mises a jour de Windows pouvaient engendrer des pb a l'utilisation d'appli a cause de changements dans les DLLs. J'ai toutes les raisons de croire la personne qui m'a affirmé ça mais son expérience date de de quelques années (epoque de VC++ 6.0 et nous sommes passés a VS2005).

voici donc mes questions:
1) Est-ce que ce risque est réel et se rencontre "couramment" ou est-ce plus un risque théorique ...
2) le changement de compilateur VC++6 ->2005 peut-il influer (en bon ou en mauvais) sur ce pb
3) si le risque existe toujours, comment le prévenir ? Je précise que les machines que nous déployions ne sont pas connectées a internet donc pas de risque de MAJ parasite mais nos machines de dev le sont elles...

Merci de vos avis et n'hésiter pas a poser des questions si cela est nécessaire

V

[TheGzD]

1/ le risque est bien réel, d'ailleurs si tu utilises les mfc par exemple, tu risques de devoir installer le package redistribuable sur les ordinateurs ne disposant pas de VS

2/ la rétrocompatibilité est normalement assurée, mais bon tu prends un risque : à toi de voir

3/ en liant les dépendances statiquement à ton exécutable/ ta librairie : c'est plus volumineux, mais normalement sans mauvaise surprise

Je base ceci sur mon expérience, après je n'affirme pas avoir 100% raison.
Quoi qu'il en soit, bon courage

[vdaanen]

Slt

1/ le risque est bien réel, d'ailleurs si tu utilises les mfc par exemple, tu risques de devoir installer le package redistribuable sur les ordinateurs ne disposant pas de VS

oui, j'avais prevu ca ...

2/ la rétrocompatibilité est normalement assurée, mais bon tu prends un risque : à toi de voir

As-tu deja rencontré ce genre de pb ? comment les as-tu gérés ? recompil du programme ?
Est-ce courant comme pb (1/2 fois par semaine/mois/an) ?
Ce qui me surprend en fait, c'est que les applis qui sont basées sur les MFC en DLL ne sont pas mise a jour frequemment donc je me dis que les DLLs MFC doivent etre dans un etat relativement stable, ou du moins pas mis a jour tres frequemment ....

3/ en liant les dépendances statiquement à ton exécutable/ ta librairie : c'est plus volumineux, mais normalement sans mauvaise surprise

oui, c'est qui avait conduit au premier choix, toutefois ca pose des pb, notamment le partage de memoire entre DLL et application d'une part mais aussi on envisage de passer nos GUI sous QT et la, on doit entre en "MFC-shared lib" si on veut pas debourser plusieurs dizaine de k€

Je base ceci sur mon expérience, après je n'affirme pas avoir 100% raison.
Quoi qu'il en soit, bon courage

merci

[bacelar]

Franchement, le plus gros problème vient de librairies et de leur API mal conçu qui oblige au big-bang de tout le monde doit utiliser la même C-Runtime.
Il en suffit d'une avec les mauvaises options, sans les sources, et vous êtes dans la moïse.

1) Est-ce que ce risque est réel et se rencontre "couramment" ou est-ce plus un risque théorique ...

Le problème, plus que d'être lié à des problèmes de mis à jour des dll Windows, est un problème de portabilité sur les différents OS Windows.
A l'époque, par exemple, il y avait des bugs de libération mémoire dans la C-Runtime dll de Win95 et le cycle de paching de l'époque n'avait rien à voir avec l'actuel.
Donc, une application qui marchait correctement sous WinNt pouvait fuir sous Win95.

L'utilisation du SxS (Side by Side) de la C-Runtime application par application permet de s'isoler des modifications de la C-Runtime de l'OS.
Donc si VS2005 gère le SxS, comme je le crois, plus de problème, s'il existait.

2) le changement de compilateur VC++6 ->2005 peut-il influer (en bon ou en mauvais) sur ce pb

Bin oui

3) si le risque existe toujours, comment le prévenir ? Je précise que les machines que nous déployions ne sont pas connectées a internet donc pas de risque de MAJ parasite mais nos machines de dev le sont elles...

Le problème de compatibilité avec de librairies males fagotées restent un risque majeur.
Pour prévenir, comme toujours, des tests unitaires exhaustifs et exécutés régulièrement.
Définir aussi correctement le problème, car le problème des montés de version des dll, c’est très très vague. Cela permettra de vérifier le problème et de vérifier que la mise en place d’outils de corrections comme le SxS le prévient.

[TheGzD]

oui, c'est qui avait conduit au premier choix, toutefois ca pose des pb, notamment le partage de memoire entre DLL et application d'une part mais aussi on envisage de passer nos GUI sous QT et la, on doit entre en "MFC-shared lib" si on veut pas debourser plusieurs dizaine de k€

le prix de la tranquillité il faut croire