Discussion :

[vg-matrix]

tout le monde, je suis nouveau sur la plateforme .NET avec Visual Basic Express mais je me suis mélangé les pédales. J'ai installé Visual Basic Express 2008 sp1 sur mon pc (processeur Pentium Dual Core x64 avec Xp Pro 32 bits) mais j'aimerais que les applications soient compilées pour les systèmes 32 bits. Mon deuxième problème est le type de la base de données à installer sans oublier que je développe exclusivement pour les systèmes 32 bits parce j'ai installé Sql server management 2005 mais il ne détecte aucune instance de Sql compact 3.5 sp1 ou sql server express 2008. Du coup j'arrive pas à me connecter à une base de données.

Que dois-je faire? Aidez-moi s'il vous plaît

[mrtrampo]

Salut je ne peux t'aider que pour le type de plateforme pour laquelle ton programme est compilé :

• Lorsque ton projet est ouvert, dans l'explorateur de solution tu double clique sur l'élément qui s'appelle "My Project"
• Tu sélectionnes l'onglet "Compiler" à gauche
• Parmis tous les éléments de cet onglet, tout en bas à gauche cliques sur le bouton "Options avancées de compilation"
• Et là dans la combobox du milieu de la partie inférieure de la fenêtre tu sélectionnes x86 pour les plateformes 32 bits

(petite précision, je suis souc visual studio 2008, l'interface est peut être différente de celle de Visual Basic Express 2008)

[Pol63]

ou sinon laisser anycpu, ca fonctionne en x86 sur un x86 et en x64 sur un os x64, donc c'est optimisé ...

[ctxnop]

Ah non, le AnyCPU n'est pas optimisé... C'est juste portable et donc plus pratique. Mais ca n'est pas plus optimisé qu'un développement ciblant une architecture précise, j'aurais même tendance a dire le contraire. De plus ca amène également beaucoup de limitations qu'il faut parfois prendre en compte.
Par exemple, développer un plugin pour une application 32bit ne peut pas être fait en AnyCPU, car sur une machine 64Bit il se chargera en tant que code 64bit et donc provoquera une BadImageFormatException alors que s'il cible le 32bit il se chargera sans encombre.
Sur le même principe, développer SUR une machine 64bits empêche certaines fonctions du debuggueur de Visual Studio. En effet, comme celui-ci est écrit en 32bit, il ne peut pas débugguer un code 64bit avec toutes les fonctionnalités (par exemple, la fonction "Modifier & Continuer" ne peut être utilisée).

Pour définir la cible d'un projet (car il faut le faire projet par projet et non pas sur la solution) il faut aller dans les propriétés et changer la cible pour "x86".
Attention, ne pas se laisser abuser par la double liste déroulante (Debug/Release + AnyCpu/x86/x64), celle-ci ne donne que le nom d'une configuration et non pas la configuration elle-même. Autrement dit, sélectionner x64 dans cette liste n'assure en rien que le projet sera généré pour du x64.
En bref, la méthode de mrtrampo est la bonne, tout autre est mauvaise.

Quand au problème de SQL, navré mais j'en ai aucune foutue idée, déjà que taper 2 requêtes avec une pauvre jointure ca me saoul, alors l'administration de ces serveur ...

[methylene]

+1 ctxnop

J'ai lu rapidement le topic, et je te rajouterais ce lien vers un ancien topic, un peu dans le même genre de problème : ici.

[Pol63]

Ah non, le AnyCPU n'est pas optimisé...

!?

le anycpu permet d'optimiser l'exécution du programme

si tu le compiles en x86 et que tu l'exécutes sur du x64 il marchera en x86
mais compilé en anycpu, la compilation du JIT sur un OS x64 sera en x64, et donc ne me dit pas qu'on y gagne pas un peu ...

après oui, développer en x86 permet de débugger ^^ mais rien n'empêche de remettre anycpu pour déployer
(d'ailleurs vs2010 corrige t il cela ?)



@vg-matrix
rien compris à ton problème de base de données ...

[ctxnop]

Non pas du tout.
Ce qui permet d'optimiser le programme c'est de cocher les options d'optimisations (pré-cochées en profile release).
Quelle que soit la cible, la compilation génère du bytecode MSIL. En théorie, le même, puisque destiné à une machine virtuelle normalisée. Donc le x86 n'est pas plus optimisé que le AnyCPU, mais AnyCPU n'est pas non plus plus optimisé que x86.
Par contre, cibler AnyCPU fait que l'exécutable se charge en tant que processus "natif" (ici natif est au sens que sur machine 32bit il se charge en 32bit et sur une 64bit il se charge en 64bit, rien a voir avec l'assembleur ou je ne sais quoi d'autre).
Cibler x64 fera que l'exécutable se charge systématiquement en tant que processus 64bit, ce qui le rend inutilisable sur machine 32bit.
Cibler x86 fera que l'exécutable se charge systématiquement en tant que processus 32bit, ce qui fait qu'il tourne normalement sur machine 32bit (aussi bien que le x64 sur 64bit) mais il tournera en multilib sur une machine 64bit. Pour autant que je sache ca ne ralenti pas l'exécution du programme.
Et si jamais ca le fait, ca ralentit beaucoup moins que le passage par la machine virtuelle .Net, si tu en est à vouloir compter cette "optimisation" il est temps de songer à coder en C++, en C voire en assembleur.

--Edit
Au fait, oui on peut tout à fait mettre AnyCPU pour déployer. Mais ce n'est pas toujours faisable. Par exemple moi, dans mon boulot, le programme sur lequel je travail est amené à être installé sur tout type de bécanne et donc aussi bien du 32bits que du 64bits. En conséquence on pense naturellement qu'il faut cibler le AnyCPU. Sauf que non, ca ne marche pas. Pourquoi ? Parce que certains composants tiers ont été compilés en x86 pour des raisons plus ou moins valables (j'entend par la qu'il nous est arrivé de demander une version AnyCPU et qu'on ne l'a pas toujours obtenue car parfois il ne peuvent pas changer la cible).
En conséquence on ne peut pas utiliser le AnyCPU car les composants x86 ne se chargent pas sur une machine 64bit. Le AppDomain étant x64 il refuse de charger en x86.
--Edit

Et pour répondre a ta question : non, Visual Studio 2010 souffre toujours des même problèmes. "Pire", la cible par défaut de Visual Studio est maintenant le x86 et non plus le AnyCPU, la raison invoquée est justement les problèmes en Debug. Il faut savoir que les nouveautés du debuggueur de 2010 (qui sont tout de meme une grande partie des keyfeatures) sont toutes inutilisable en 64bit.

[Pol63]

je ne parle pas de performance de la précompilation qui est en effet la même du fait du msil
mais sur la machine finale, utilisé en x64 ca tire parti des instructions x64 donc ca ne peut etre que plus performant (sinon le .net n'a pas lieu d'être étant un langage interpreté)

après oui des dll com ou même microsoft jet sont en x86 et donc nécessite de ne cibler que l'x86

[sinople]

Vous êtes sur que l'on peut changer cela dans les versions express (2008)?

J'ai beau fouiller toutes les propriétés du projet, je n'ai rien trouvé qui ressemble à cette option.

Sinon sur le sujet 32 ou 64 bits, je pense que le 32 est plus approprié vu que l'on se trouve encore dans une période de transition vers le 64 bits et que de loin pas toutes les machines (et référence) touchée par ton projet vont le gérer.

Donc le 64 bits, à part dans un environnement maîtrisé de A-Z pour une application pointu niveau optimisation j'éviterai. (Et dans ce cas de figure je pense que c'est .Net qui faudrait éviter...)

[ctxnop]

Les expériences ont plutôt montré l'inverse, le 64bit étant moins performant que le 32bit.
Bien sur, ce n'est pas systématiquement le cas. Soyons clair, qu'est-ce qu'apporte le 64bit ?
- Un adressage directe en 64bit (autrement dit en une seule instruction) donc plus de RAM par exemple.
- Des registres en 64 bits (pour y placer un nombre/pointeur)
- ... Bah en fait c'est à peu près tout.

Alors c'est bien mais a quoi ca sert ? Dans les fait ca sert quasiment a rien. En 32 bits on peut adresser 4Go de mémoire et faire tenir un nombre d'environ 4 milliards. C'est suffisant dans la pluspart des cas. Autrement dit, le 64bits n'apporte quelque chose que lorsqu'on dépasse ces limites. Parrallèlement il apporte aussi un surpoid puisque les pointeurs pèsent 8 octets au lieu de 4.

Bon voila, je rentre pas trop dans les détails car je ne voudrais pas parler de quelque chose que je ne maitrise pas bien, beaucoup crieront sans doute au scandale rien qu'avec ces quelques lignes.
Tout ca pour dire que la diff de perf entre le 32 et le 64bit ne justifie pas un choix de plateforme cible. Ca n'a rien de plus optimisé, ca ne l'est pas moins pour autant, ca apporte la portabilité et c'est déjà beaucoup. Et si tu compte ce possible gain de perf sur machine 64 bit, dans ce cas tu ne code pas dans un langage qui passe par une machine virtuelle. Encore une fois, le temps "perdu" dans cette machine virtuelle et "l'interprétation" du MSIL est infiniment plus important que les 4 cycles processeur que tu pourrais éventuellement gagner sur une machine 64bit.

[Pol63]

SCANDALE !

(ca c'est fait ^^)

l'interprétation du msil est faite à chaque exécution mais la compilation des classes et membres n'est faite qu'une fois lors de la première utilisation
le .net est à mon avis interpreté dans le but de faire la compilation spécifiquement pour la machine (plutot qu'un programme c qui est compilé 10x par le développeur et qu'il faut télécharger le bon)

en effet qu'on se trouve sur un pentium 3 ou un core i7, le jeu d'instruction n'est pas le même, donc au moins le compilateur JIT doit prendre ce qu'il y a de mieux selon le pc
et le x64 amd64 n'apporte pas que de l'adressage, il y a des dizaines d'instructions processeur en plus ...
biensur tout ca n'est que mon point de vue empirique, bien que n'ayant pas encore fait de test chronométré entre x86 et x64 ('vais surement tenter à l'occasion)

[ctxnop]

Je n'ai pas remis en cause le fait que le msil est fait pour tourner aussi bien sur le 32bit que sur le 64.
Les instructions qu'apporte le 64bit sont faite pour faire mumuse avec les données ... 64bits. Donc on en revient à ce que je disais, tant que tu dépasse pas les limites du 32bits, aucune différence (ou presque).
Si tu te lances dans les tests fait attention d'être exhaustif avant de conclure. Comme je l'ai dit plus haut, dans certains cas le 64bit est plus performant que le 32bit, et inversement. Créer un seul et unique test pour montrer que le 64bit est plus performant n'a aucune valeur. On trouve déjà plein de benchmark sur le sujet. Et énormément d'article qui datent de quelques années (a l'apparition des système 64bits pour grand publique) sur lesquels on explique les impactes, les différences, les incompatibilités, ...
Je te souhaite une bonne lecture

[The_badger_man]

C'est sympa tout ça mais ça ne règle pas le problème initial.

mais j'aimerais que les applications soient compilées pour les systèmes 32 bits.

Tu veux compiler EXCLUSIVEMENT pour 32 bits ou tu veux simplement que ça fonctionne sur 32 bits ? Pour le 1 tu as la solution ci-dessus, pour le 2 t'as rien à faire. Ton .exe fonctionnera sur 32 et 64 bits.

j'ai installé Sql server management 2005 mais il ne détecte aucune instance de Sql compact 3.5 sp1 ou sql server express 2008.

C'est pas ça le problème ? Pour ne pas avoir installé Management Studio 2008 si tu utilises SQL Server 2008 Express ?
http://www.microsoft.com/downloads/d...displaylang=en

[sinople]

en effet qu'on se trouve sur un pentium 3 ou un core i7, le jeu d'instruction n'est pas le même, donc au moins le compilateur JIT doit prendre ce qu'il y a de mieux selon le pc
et le x64 amd64 n'apporte pas que de l'adressage, il y a des dizaines d'instructions processeur en plus ...

Ouais mais la différence de perf entre le i7 et le pentium 3 je suis pas persuadé que ça vient du 32bits / 64bits.

[ctxnop]

Ouais mais la différence de perf entre le i7 et le pentium 3 je suis pas persuadé que ça vient du 32bits / 64bits.

J'avais pas osé la faire ^^'

[Pol63]

lol

en meme temps un pentium 3 avec du refroidissement à l'azote ca doit pouvoir grimper

[vg-matrix]

C'est vraiment très compliquer pour moi qui développe des applications destinées à fonctionner sur les systèmes 32 bits. Je me disais que Visual Studio allait pallier à ce complexe, mais je vois que c'est moins compliqué en Delphi, parce que là ou moins je ne fais que du 32 bits sans parler de 64 bits.

[Pol63]

bah si tu définis que tu veux du 32 bits ca fait du 32bits
je ne vois pas ce qu'il y a de compliqué ...