.exe non portable?

**poukill** · 13/06/2006, 08h24

Envoyé par Mayti4

Tu programmes en .NET ?

Effectivement ! C'est tout à fait le problème avec lequel je fais face actuellement !
Sauf que le message d'erreur n'est pas tout à fait celui-là (cf pièce jointe)...
Mais il me semble bien que le fond du problème soit bien ça...

Merci Mayti4 !

**poukill** · 13/06/2006, 08h31

Au fait, programmer en .NET veut donc dire que le programme n'est pas "portable"????

Dites moi si je me trompe ?

**Matthieu Brucher** · 13/06/2006, 08h38

Programmer en .NET, c'est utiliser le framework Microsot avec les assembly de Microsoft, compiler en managé, ... C'est peut-être portable -> Mono

**poukill** · 13/06/2006, 08h40

Pourtant, je n'utilise rien de tout ça dans mon environnement de développement !!! C'est juste du C++ !!! Je n'utilise pas les MFC et autres???

Que faut-il faire pour se débarasser de ce Framework Miles???

**poukill** · 13/06/2006, 08h41

Envoyé par Miles

C'est peut-être portable -> Mono

Je ne comprends pas !

**Matthieu Brucher** · 13/06/2006, 08h48

Mono est un portage de .Net sous Linux.

Si tu ne fais que du C++, commence par virer le fait de compiler le code en code managé - dans la première page des propriétés d'un projet -

**poukill** · 13/06/2006, 08h57

Envoyé par Miles

Mono est un portage de .Net sous Linux.

Si tu ne fais que du C++, commence par virer le fait de compiler le code en code managé - dans la première page des propriétés d'un projet -

OK ça c'est fait... Je vais tester dès que je peux en salle de controle, et je te tiens au courant!
J'espère que ça va marcher !

Une autre petite question Miles (merci pour ta gentillesse!): que peut apporter le .NET en plus par rapport à un projet classique?

**Matthieu Brucher** · 13/06/2006, 09h05

Ce que ça apporte ?
Je pense que cette question, il vaut mieux la poser à des spécialistes ici : http://www.developpez.net/forums/forumdisplay.php?f=55 Qui sait, il y a déjà la réponse

**poukill** · 13/06/2006, 09h21

OK OK je vois... Si j'ai bien compris, ça s'implante partout cette p'tite bête là...
Je vais essayer de faire installer ce framework, et en attendant, j'espère que la version que je viens de compiler va marcher!

@+ et merci encore

**poukill** · 15/06/2006, 12h07

Désolé de remettre ce "vieux dossier" sur la pile, MAIS...
deux trois choses me dérangent encore à ce sujet, alors autant compléter ce topic!

Effectivement, décocher l'option "code managé" me permet de me passer de ce framework .NET!
Cependant, il reste plusieurs incomptabilités avec d'autres PC:

manque les librairies msvcr71.dll et msvcp71.dll
Là, c'est sous 2000 (et sans framework apparemment...)
Pourquoi mon programme a t-il besoin de ces dll. Est-ce qu'il y a un rapport avec les options de compliation (/MD) ou pas???

Bref, je m'interroge

**Médinoc** · 15/06/2006, 14h18

Oui, c'est la C Run-Time Library et la C++ Library version 7.1 (la version de VS2003).
Apparemment, ce sont les version Release des bibliothèques, elles devraient donc exister sur le poste destinataire...

Essaie de voir si tu peux en copiant directement les DLLs en question dans le répertoire de l'application... On verra bien si ça marche ou s'il y a des "sécurités" qui l'empêchent...

**poukill** · 15/06/2006, 14h24

oui oui ça marche si j'inclue dans le dossier de mon éxécutable les deux dll ci-nommées...

Mais je comprend pas pourquoi tant de précautions à prendre...
Je m'attendais vraiment à ce que une fois mon programme validé sur mon PC, il marche sur les autres....

C'est quand même pas trop demander!

Hé ben non...

**Médinoc** · 15/06/2006, 14h30

Ces DLLs sont supposées être un peu partout, mais au moins elles sont redistribuables...
C'est comme MFC, il n'est pas rare qu'un programme possède sa propre copie des DLLs de sa version de MFC au cas où elles ne seraient pas installées...

**poukill** · 15/06/2006, 14h37

Ok, je vais me trimballer avec mes DLL sur moi !

Merci Médinoc

Juste une dernière question, si je compile mon programme en /MT, y aura t-il une différence???
Ce n'est peut-être pas souhaitable de toute façon, mais je pose la question!

**Médinoc** · 15/06/2006, 14h41

Si tu compiles en /MT, tu n'auras pas besoin de transporter les DLLs de la CRT, mais tes exécutables gonfleront comme un dragon des marais devant un miroir, et si tu as des DLLs persos, je crois bien qu'elles ne doivent pas être en /MT (sous peine de causer des incompatibilités notoires, mais c'est peut-être juste une connerie)

**poukill** · 15/06/2006, 14h46

Mes DLL existent en deux versions : /MT et /MD...
j'ai donc deux choix pour la compilation de mon projet...

Dans le doute... je vais rester /MD

**Matthieu Brucher** · 15/06/2006, 16h15

En général, sur un poste neuf, les bibliothèques ne sont pas présentes, il faut avoir au moins une fois installé un logiciel qui en avait besoin.
Pour le /MT ou /MD, certains bibliothèques sur le net sont compilées en /MD et alors tu n'auras pas le choix.

**picsou33** · 16/06/2006, 10h38

euh, j'ai moi aussi un probleme de portabilité et je voudrais savoir ce que sont c'est /MT et /MD...
merci bien

(je suis tout nouveau ds le monde du dev windows)

**Matthieu Brucher** · 16/06/2006, 10h45

Regarde dans les options de compilation...
/MT, c'est compilation multithread avec la bibliothèque statique, /MD, c'est multithread avec la dynamique.

**poukill** · 16/06/2006, 10h57

Envoyé par Miles

En général, sur un poste neuf, les bibliothèques ne sont pas présentes, il faut avoir au moins une fois installé un logiciel qui en avait besoin.
Pour le /MT ou /MD, certains bibliothèques sur le net sont compilées en /MD et alors tu n'auras pas le choix.

Est-ce que ça veut dire : Tu dois rester dans le même IDE, à savoir Visual C++.NET ???

Moi qui voulais un jour revenir à Code::Blocks (gratuit...)