Compilation /MD /MT dans VS 2005

Bonjour,

Un projet existant sous VS 2003 était compilé avec l'option /MT (car il gère plusieurs threads)

J'ai retravaillé sur cette application, notament pour y ajouter une prise en charge de Web Service (automatique avec sproxy), j'ai donc été obligé d'ajouter /clr pour la compilation.

Hors, /clr m'interdit d'utiliser /MT j'ai donc utilisé /MD ...mais je n'en connais pas la différence.
La compilation se passe bien, mais j'ai quelques comportement différents entre les deux versions..

Quelles sont les conséquences d'une compilation avec /MD par rapport à /MT ?

/MT : Liaison statique avec la C Run-Time library : Un gros exécutable, indépendant de MSVCRT/MSVCR71/MSVCR80.DLL. Par contre, risque de problèmes si tu utilises des DLLs.

/MD : Utilise la DLL pour la C Run-Time library : Un exécutable plus petit, mais qui a besoin d'avoir la bonne version de la DLL (voire plus, pour la version 8)sur le PC de destination. Mais normalement, pas de problème avec les autres DLLs, car il me semble qu'une DLL est obligatoirement compilée en /MD.

Ok...

Ok, le soucis, c'est qu'apparement, on ne peut pas faire cohabiter /MT et /clr.
Hors quand je compile en /MD, mon programme un comportement bizarre...plus quelques erreurs au lancement de programmes connexes :

Code:

---

1 2	System.IO.__Error.WinIOError(...) C:\(...)\Local Settings\Temp\(nomaleatoire).dll introuvable...

---

Comme je ne comprends pas réellement les différences de comportement entre un exe en /MT et en /MD, je ne comprends pas d'ou viennent les erreurs....

Donc ma question :

Si je veux un gros exécutable avec tout dedans (parceque je ne vois pas comment générer de DLLs) et pouvoir utiliser les fonctions CLR, comment puis-je faire ?

Il n'est pas question ici de générer des DLLs, mais d'utiliser une DLL déjà fournie par Microsoft.

Et le .Net ne permet pas de lier statiquement à la CRT, tu n'as donc pas le choix: Tu dois compiler en /MD et garder à l'esprit que tu dois avoir à portée de main la DLL de la CRT...
(pour VS2003, elle doit s'appeler MSVCR71.DLL, et la bibliothèque standard C++ est MSVCP71.DLL)

Je compile avec VS2005 :

Sur mon poste client, j'ai bien msvcr80.dll dans C:\Windows\WinSxS\x86_Microsoft.VC80.CRT_(caractere aleatoire)
à plusieurs endroits (caractère aléatoire différent)

par contre, j'ai la msvcr7.1.dll dans System32 et dans le dossier du framework .NET 1.1 , et bizarrement pas dans le .NET 2.0

Faut-il que j'en mette une copie à coté de mon exe., ou dans System32 ou cela suffit-il ?

Pour VS2005, C'est MSVCR80.DLL.

Dans ma version pro, j'ai un dossier Redist, qui contient un dossier Microsoft.VC80.CRT, lequel renferme tous les fichiers nécessaires (des DLL et un manifest).
Normalement, une copie du dossier avec l'exe suffit.

Qd je génère mon .exe, je n'ai qu'un .exe qui se crée dans le dossier bin/

Sans doute existe-t-il une option de compilation pour générer les redist...


Sinon, j'ai installé "vcredist_x86-sp1.exe" sur mon poste client après avoir lu que ca pouvait servir pour faire fonctionner les programmes....peut être que ca n'est pas la bonne version...

Euh...
On ne crée pas les redist... Ils ont étés créés une bonne fois pour toutes par Billou et ses amis...

Mais pour commencer, tu as essayé ton programme /clr /MD sur ton poste client ?
Il compile ?
Il linke ?
Il tourne ?

Ok, j'ai trouvé le dossier redist de VC8 "VC\redist\x86\Microsoft.VC80.CRT" , j'ai copié tout ce qui il avait dedans à coté de mon exe...

Wait n See


Toujours l'erreur du premier post.... (alors qu'elle n'arrive pas qd je compile avec MT et sans /clr )

Mon programme fait parti d'une solution qui contient 9 executables...
L'executable central, contient un Thread qui écoute un port TCP et qui attend des données des autres appli...
Cela a initialement été developpé sous VS6 puis VS2003 (et pas par moi)

Compilé avec /MT sous VS2005 tout fonctionne bien... (apres quelques heures de debug qd meme).

Mais j'ai du rajouter une fonction qui dialogue avec un WebService, pour ca j'ai utilisé l'importation automatique de Web Reference (un type managé donc...)
Pour que cela se compile, je dois compiler avec /clr /MD...

La compilation fonctionne, l'éxecution fonctionne aussi sur le client, sauf que j'ai l'erreur du début à un certain moment...

En fait, c'est encore plus compliqué...Mais je vais avoir du mal à tout expliquer...

En cours de résolution grâce à l'excellent tutoriel
http://nico-pyright.developpez.com/t.../managedworld/

et l'utilisation de #pragma managed/unmanaged !!!!

je suis ravi qu'il te plaise :D