Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Distribution x86 et x64
Bonjour à tous,
J'ai relu le tutoriel et il doit y avoir un truc que je n'ai pas compris.
J'ai développé une appli VB2010 sur une machine x64. J'ai fait un package d'install.
Tout se passe bien sur une machine x64 mais pas sur une x86.
Pourtant je pensais que si je mettais le TargetPlatform en x86 tout irait bien.
Est ce que quelqu'un a une idée ?
Normalement oui (tu peux aussi mettre AnyCPU). Mais tout dépend de ce que fait ton code. Par exemple si tu utilises des API Win32 avec DllImport, il faut faire gaffe à la déclaration des types.Envoyé par Pascal Lob
Tu es sûr que le problème vient de là ? Le fait que ce soit du x64 ou x86 n'est peut-être pas la seule différence entre les deux machines. Par exemple, est-ce que le framework 4.0 est bien installé ?
Pas de questions techniques par MP ! Le forum est là pour ça...
Tutoriels : Les nouveautés de C# 6 - Accès aux données avec Dapper - Extraction de données de pages web à l'aide de HTML Agility Pack - La sérialisation XML avec .NET (Aller plus loin) - Les markup extensions en WPF
Je ne suis sur de rien. Après avoir constaté le pb, J'ai monté différentes machines virtuelle x68 et ça ne fonctionne pas.
Mais j'ai un peu avancé depuis. C'est ADODB qui pose pb.
Le reste est fonctionnel.
Visual Studio n'a pas ajouté adodb dans les dépendences détectées.
et je ne trouve pas comment lui imposer.
ADODB est obsolète depuis une bonne dizaine d'années
Pourquoi ne pas utiliser plutôt ADO.NET ?
Salut,
lit le sujet que j'ai ouvert il y pas longtemps ça pourra peut être t'aider : http://www.developpez.net/forums/d12...llation-setup/
Merci mais ce n'est pas un problème de répertoire d'installation. J'ai ajouté un message à ton sujet d'ailleur.
Bin j'en sais rien. probablement par habitude. Ceci dit dans mes références .NET je n'ai trouvé que adodb pas de ado tout court. Il y a bien un dao est ce la même chose ?ADODB est obsolète depuis une bonne dizaine d'années
Pourquoi ne pas utiliser plutôt ADO.NET ?
Ce qui est très étonnant. C’est que la connexion à la base s’ouvrait bien mais toutes les autres fonctions plantaient.
Suivant les conseils trouvés sur le site Microsoft j'ai sélectionné la référence ADODB et j'ai modifié ses propriétés:
Incorporer les types Interop = false
Copie Locale = True
du coup dans le projet de déploiement je retrouve bien adodb en dépendance détectée.
Par contre malgré de nombreuses tentatives d'install il n'y avait pas de modification jusqu'à ce que je me rende compte que dans le panneau de config/ajout de programmes, je retrouvais autant de fois mon programme que de tentatives d’install.
J’ai supprimé le premier de la liste, plus de trace de mon programme sur C:/program files/ mais toujours 7 ou 8 fois dans la liste des prog.
Je les ai toutes supprimées puis j’ai relancé l’install et cette fois tout marche bien.
Alors soit je n’ai rien compris à la manière de faire ces assembly, soit ce n’est pas tout a fait au point.
Merci de vos interventions, je vous laisse un peu de temps pour répondre ou commenter avant de cliquer sur résolu.
adodb tu as dû le trouver plutôt dans la catégorie COM que .NET...
ADO.NET c'est l'assembly System.Data (la référence est généralement ajoutée par défaut aux nouveaux projets)
Je ne sais pas ou il doit être habituellement mais le adodb que j'ai utilisé est bien dans la liste des .NET
Par contre je ne trouve aucun ado dans les .Net alors qu'il y a
microsoft Ado data control 6.0(OLEDB)
microsoft ADO Ext 2.8 for DLL and Security
microsoft ADO Ext 6.0 for DLL and Security
dans la liste des .COM
c'est grave docteur
Répondre avec citation
Partager