Probleme VB entre windows7 et windowsXP

Bonjour,

J'ai récupéré les fichiers sources d'un programme qui permet de contrôler un appareil photo. Et j'ai un problème que je trouve très bizarre - en tout cas je n'en comprend pas l'origine : si j'ouvre le projet dans Visual Studio 2008 sous windows7 et que je lance le déboggage, le programme génère une erreur. Par contre, si je refais exactement la même chose dans un visual Studio 2008 sous windows XP tout fonctionne parfaitement. Merci de m'aider si vous avez une idée de la source du problème.

Si tu ne détailles pas en quoi consiste l'erreur n'espère pas de l'aide. Personne ici ne fait dans la voyance, le tarot ou autre pratique divinatoire.

C'est comme si on répondait à un problème "moi j'ai la solution", sous-entendu "à toi de la deviner maintenant". Alors faite un effort quand vous postez et mettez vous à la place de ceux qui voudront bien vous répondre.

c'est quand même fou la recrudescence de topic avec "j'ai un erreur, devinez laquelle et donnez moi la solution"

c'est quelque chose que je ne comprendrais jamais ...
on est quand même pas derrière votre écran ! il faut se mettre un peu à la place de celui qui va vous lire !

Halala... Mea culpa, mea maxima culpa !
Il est vrai que je n'ai pas décrit l'erreur, mais... ce n'était pas par oubli ou par volonté de recourir aux arts divinatoires : j'avais surtout l'impression que l'erreur n'est pas le problème réel.
J'ai donc les fichiers sources d'un programme. Lorsque j'importe le projet VB dans visual studio 2008 et que je lance le déboggage, le programme génère une erreur

Citation:

---

La référence d'objet n'est pas définie à une instance d'un objet.

---

(pour être précis, donc)
MAIS cette erreur n'apparait que si je lance le deboggage sous windows7. Si je lance le deboggage sur un visual studio qui tourne sous windowsXP, le programme fonctionne très bien.
Mon idée - mais c'est à niveau que je demandais un coup de main, pas pour la résolution de l'erreur elle-même - est que, le code étant le même entre les deux essais, le problème ne vient pas de lui mais d'ailleurs.... et je ne vois pas d'où. Alors merci si vous avez une idée.

ce que te sembles anodin peut signifier quelque chose pour celui qui va te répondre
avec la ligne qui passe en erreur on aurait plus de chances de trouver le problème exact ...

à tenter :
clic droit sur le ou les projets (au moins l'exe en théorie)
propriétés
onglet compiler
bouton options de compilations avancées
mettre x86 à la place de AnyCpu dans le combobox et valider

Citation:

---

Envoyé par mBlast

le code étant le même entre les deux essais, le problème ne vient pas de lui mais d'ailleurs

---

Le problème pourrait tout à fait venir du code. Par exemple, une requête WMI qui renverrait quelque chose de différent entre un poste XP et Seven, en renvoyant null dans le second cas par exemple (et si on utilise ça sans le tester ça produit l'erreur en question). C'est juste un exemple, mais suivant ce que tu utilises il peut parfaitement y avoir des différences de comportement sans que le code ne change.

Sans voir la zone qui pose problème difficile donc de mettre cette piste complément de côté. Mais une exception ArgumentNullException c'est généralement lié au code d'une façon ou d'une autre ;)

YES ! Merci Pol63 : c'était bien le compilateur en anyCPU qui posait problème, en x86 tout fonctionne très bien. Et promis, la prochaine fois je dit tout, même ce qui me semble anodin.

quelques informations sur le problème quand même :
AnyCpu fait que l'exe va être exécuté en x86 sur un os x86 et en x64 sur un os x64, tirant parti des évolutions du x64 automatiquement et sans avoir à compiler 2 .exe différents
une fois le choix fait par .net à l'exécution, il charge les dll que tu as utilisé dans le mode choisit par l'exe

certaines dll surtout non managés (= non .net) ne peuvent fonctionner qu'en x86 ou qu'en x64 (connexion à access ou oracle selon le provider, ou autre dll tierce)

Citation:

---

Envoyé par Pol63

AnyCpu fait que l'exe va être exécuté en x86 sur un os x86 et en x64 sur un os x64, tirant parti des évolutions du x64 automatiquement et sans avoir à compiler 2 .exe différents

---

J'approfondis la reflexion sur ce fait, car j'ai deja eu un probleme similaire et que tu connais peut-etre une solution.
J'avais donc une petite appli .net 2.0 genere sous anycpu qui fonctionnait bien dans 99% des cas, mais qui sur certains systemes (x64) plantait allegrement et aleatoirement. J'ai cherche a passer l'execution de l'exe en x86 juste pour essayer (sans recompilation donc) mais sans trouver solution.
Donc ma question : Comment faire pour forcer l'execution en x86 sous un sys x64 avec un exe genere sous AnyCpu ? (si c'est possible bien sur)

moi non, mais google a l'air

http://www.google.fr/#q=exécuter+.net+x86+force
qui donne
http://stackoverflow.com/questions/1...u-net-assembly
pas lu en entier mais la première réponse a l'air d'être pas mal

Effectivement ca corresponds exactement a ce que je desirais faire.
Pour info, voici comment faire : http://msdn.microsoft.com/en-us/libr...8VS.80%29.aspx