Discussion :

[ousmane126]

Bonjour à tous,

Je suis entrain de travailler sur un projet depuis maintenant 2 mois (création d'un système d'acquisition de donnéeS). J'utilise Visual Studio 2013. Je viens de finir la partie code de mon programme, cependant je voulais savoir si au cas ou je crée mon executable est ce que mon programme pourra tourner sur une autre machine qui n'a pas forcement visual studio? mon objectif serait qu'il puisse tourner après sur n'importe qu'elle machine. j'aurai une deuxième question qui concerne l'execution de mon fichier executable: j'ai réussi a créer le fichier executable grâce à Installshield cependant lorsque je le lance sur une autre machine il me met l'erreur suivante : "La référence d'objet n'est pas définie à une instance d'un objet". C'est l'exception "System.NullReferenceException" qui n'a pas été géré. Cependant j'ai mis des "New" à toutes les variables que j'ai déclarées, et j'ai fait des "try Catch" sur presque toutes les méthodes mais cependant le même problème apparaît. Avez vous des idées sur comment le surmonter?

Merci d'avance

[Pol63]

le but de visual studio est bien de faire des programmes qui fonctionnent sur d'autres machines, vs n'est que le logiciel permettant de faire le programme, il n'est pas nécessaire sur les autres machines
par contre dans le projet on choisit une version du framework (2, 3.5, 4, 4.5 ...) et ce framework est nécessaire sur les autres machines
dans la plupart des cas windows update l'aura mis, sinon le mieux reste de faire un setup.exe qui inclut le framework (du moins si on veut une install autonome, il reste possible de l'installer à la main et de copier l'exe)

concernant ton nullreferenceexception ceci provient surement d'un bug dans ton code, un bug ne se produire que sur certains postes, qu'à certaines dates etc... ce n'est pas forcément quelque chose qui ne marche jamais
chercher ce qui est absolu comme un chemin, une chaine de connexion ... ca peut etre aussi un manque de droits ...
les try catch interceptent les erreurs, et donc par défaut les masquent, mais il faut faire quelque chose dans le catch en vue de corriger ces erreurs
imaginons un endroit ou tu veut lire un fichier pour remplir une variable, le fichier n'existe pas sur le poste et du coup la variable n'est pas remplie, tu peux alors avoir un nullreference lors de l'accès ailleurs à cette variable

dans le catch il faut en général enregistrer les éléments de l'erreur permettant de la comprendre et de la corriger (ex.gettype.fullname, ex.message, ex.Stacktrace ...)

[wallace1]

Bonjour à tous,

cependant je voulais savoir si au cas ou je crée mon executable est ce que mon programme pourra tourner sur une autre machine qui n'a pas forcement visual studio? mon objectif serait qu'il puisse tourner après sur n'importe qu'elle machine.

Visual Studio est un environnement de développement donc lorsque tu généreras ton binaire en mode "release" (prêt à distribuer) tu le récupères à cet emplacement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

....Mes Documents\Visual Studio 2013\Projects\%LE-NOM-DE-TON-PROJET%\%LE-NOM-DE-TON-PROJET%\bin\Release

j'ai réussi a créer le fichier executable grâce à Installshield ....

On ne créé pas l'exécutable avec InstallShield, ce dernier étant un assistant d'installation d'application : lire ceci InstallShield

Peut-être que tu exposes très mal ton problème mais on dirait que tu fais l'amalgame entre le binaire généré avec VS et celui généré avec InstallShield ......

Cependant j'ai mis des "New" à toutes les variables que j'ai déclarées, et j'ai fait des "try Catch" sur presque toutes les méthodes mais cependant le même problème apparaît. Avez vous des idées sur comment le surmonter?

Merci d'avance

Tu dis avoir placés des Try Catch à toutes tes méthodes mis gères-tu les exceptions au moins, le cas échéant c'est une très mauvaise pratique de codage !!

..brefff..... si ton programme fonctionne sans empaqueter avec Installshield sur un autre PC alors il faudra certainement revoir le paramétrage de cette dernière étape.


A+

[ousmane126]

Merci beaucoup pour vos réponses rapides. Pol63 j'ai fait comme ce que t'as dit à propos du framework mais sans vraiment comprendre pourquoi mais maintenant je comprend mieux avec tes explications . Aussi pour ce qui est de la gestion des exceptions à chaque catch j'ai demandé d'afficher le message de l'exception c'est à dire un ex.Message. Ce qui est bizarre est que lorsque je lance l'application sur le PC avec lequel j'ai fait mon programme il n'y a aucune exception ni erreur qui est détectée, le programme marche bien que se soit en mode debug ou release; Cependant lorsque je le lance sur un autre PC (après avoir fait le setup.exe en joignant le framework associé grâce à InstallShield) l'exception apparaît et le pire est que le détail n'est pas donné du coup c'est la galère pour retrouver l'erreur. J'en vient donc à Wallace1; Pour ce qui est de la manière de faire l'executable au début je mettais le compilateur en mode release et je creais mon exe cependant ce dernier ne marche pas sur un autre PC( L'application ne démarre même pas) c'est pour cela que j'ai essayé une autre manière en utilisant InstallShield. Avec ce dernier au moins, l'application démarre mais plante sur l'exception NullReference dont j'avais parlé tout à l'heure.

[Pol63]

le mode debug est prévu pour les tests (il reste possible de tester en mode release)
le mode release est prévu pour le déploiement
la différence est dans le code compilé qui est différent dans les 2 modes, le programme fait la même chose mais en mode debug visual studio ajoute un peu de code permettant de debugger

à la place d'afficher ex.message il faudrait ex.message et ex.stacktrace
stacktrace est la pile des appels
si la méthode A appelle la méthode B qui elle plante, ex.stacktrace contiendra
à B
à A
permettant de voir le cheminement des appels de méthodes, la dernière étant en haut
après le mieux est d'appeler une méthode générique dans le catch, si tu avais fait ca au début au lieu de mettre msgbox (ex.message) partout tu n'aurais qu'un endroit à changer pour afficher en plus ex.stacktrace, là je suppose que tu vas le changer partout
et donc une fois que verras la pile des appels tu sauras d'où provient l'erreur, et si tu ne comprends pas pourquoi elle se produit tu pourras au moins nous donner la partie de code qui plante

sinon le mieux est aussi de ne pas afficher l'erreur, un utilisateur final ne va rien y comprendre et ca ne va pas lui faire bonne impression, tu peux enregistrer ca dans une base de données ou dans un fichier, on envoyer un mail etc...

dernière astuce pour les débutants ou les problèmes compliqués, visual studio génère des fichiers .pdb pour chaque exe et dll, en copiant ces fichiers sur le poste te posant problème à côté de l'exe tu auras aussi les numéros de lignes dans ex.Stacktrace

[ousmane126]

Merci bien Pol63 pour tes explications très claires, je vais essayer d'appliquer ce que tu me conseilles avec les ex.stackTrace et je reviendrai vers vous si je ne comprend pas comment surmonter le problème,merci. Pour ce qui est de la méthode générique dont tu parles, je n'ai pas très bien saisi ce que tu voulais dire par la. Aussi le fichier .Pdb qui est généré, ou est ce que je le trouve? j'ai regardé dans le dossier de mon application mais il n'y ai pas. Si je comprend bien il suffit que je le colle dans le même dossier que mon exe et lorsque je lancerai mon application, si une erreur est détectée j'aurai la ligne qui contient l'erreur.

[Pol63]

générique n'est pas le bon terme oui ^^

ce que je voulais dire c'est au lieu de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
sub s1
 try catch
 
 catch ex as exception
   msgbox (ex.message & vbcrlf & ex.stacktrace)
 end try
end sub
 
sub s2
 try catch
 
 catch ex as exception
   msgbox (ex.message & vbcrlf & ex.stacktrace)
 end try
end sub

c'est de faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
public class GestionErreur
 
  public shared sub Erreur(ex as exception)
    msgbox (ex.message & vbcrlf & ex.stacktrace)
  end sub
 
end class

et donc

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
sub s2
 try catch
 
 catch ex as exception
   GestionErreur.Erreur(ex)
 end try
end sub

comme ca le jour ou tu veux passer d'un affichage de l'erreur à un enregistrement tu ne perds pas du temps à faire le tour du code
d'une manière générale dès que tu as 2x le même code (ou presque) il ne faut l'écrire 2x mais le déporter (avec des paramètres s'il y a des légères différences de traitements)

les .pdb sont dans les dossiers debug et release, peut etre en fichier caché, ou sinon voir les propriétés du projet pour cocher "générer pdb"

[ousmane126]

Oui d'accord je comprend mieux. Ok je vais essayé de faire ça. Merci beaucoup Pol63

[ousmane126]

Bonjour Pol63,
J'ai appliqué tes conseils pour résoudre mon problème et voici ce que j'ai comme résultats:
-déjà lorsque je crée mon exe en passant en mode release ou debug (la manière classique : en choisissant release ou debug dans la barre d'outils et en régénérant le projet) et que je passe sur un autre ordi, ni le release ni le debug ne se lance. Je ne comprend pas pourquoi, peut être que je le fais mal
- Maintenant en passant par InstallShield, l'exe généré dans le Debug se lance alors que celui dans le release non. Pour ce qui est de l'application lancée j'ai l'exception suivante qui apparaît (je met le texte de l'application en balise) :

Code VB.net :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
************** Texte de l'exception **************
System.NullReferenceException: La référence d'objet n'est pas définie à une instance d'un objet.
   à MccDaq.CbwApi.cbDeclareRevision(Single& RevNum)
   à MccDaq.MccService.DeclareRevision(Single& revNum)
   à Data_Acquisition.frmDataDisplay.InitUL() dans C:\Users\O1431572\Desktop\1er resultats\test 1 sur ULX\Data Acquisition - Sauvegarde 4.14 test installation\Data Acquisition\ULTI02.vb:ligne 3424
   à Data_Acquisition.frmDataDisplay.frmDataDisplay_Load(Object sender, EventArgs e) dans C:\Users\O1431572\Desktop\1er resultats\test 1 sur ULX\Data Acquisition - Sauvegarde 4.14 test installation\Data Acquisition\ULTI02.vb:ligne 415
   à System.EventHandler.Invoke(Object sender, EventArgs e)
   à System.Windows.Forms.Form.OnLoad(EventArgs e)
   à System.Windows.Forms.Form.OnCreateControl()
   à System.Windows.Forms.Control.CreateControl(Boolean fIgnoreVisible)
   à System.Windows.Forms.Control.CreateControl()
   à System.Windows.Forms.Control.WmShowWindow(Message& m)
   à System.Windows.Forms.Control.WndProc(Message& m)
   à System.Windows.Forms.ScrollableControl.WndProc(Message& m)
   à System.Windows.Forms.ContainerControl.WndProc(Message& m)
   à System.Windows.Forms.Form.WmShowWindow(Message& m)
   à System.Windows.Forms.Form.WndProc(Message& m)
   à System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   à System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   à System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

Si j'ai bien compris l'ex.stackTrace mon problème est au niveau de la 1ere ligne. Le fait est que mon programme est lié à un système d'acquisition de données de température (OM-WLS-USB Temp) et pour pouvoir l'utiliser il faut que j'installe une bibliothèque (MccDaq) qui se trouve sur le CD fournit avec le système d'acquisition lui même. Du coup quand j'installe le CD, la bibliothèque se retrouve automatiquement dans les références de Visual Studio, référence que j'ajoute bien sur à mon projet. Du coup pour que mon programme fonctionne on doit connecter le système d'acquisition à l'ordinateur(port USB). Le fait est que mon système gère déjà beaucoup d'erreurs tels que la non détection de la connexion,et beaucoup d'autres. Du coup lorsque je le lance sur le PC sur lequel je fait mon programme, au cas ou la connexion n'est pas détectée le programme se lance mais un message d'erreur apparaît pour signaler que la connexion n'est pas établi et qu'il faut corriger cela pour continuer. Du coup au cas ou je lance mon programme sur un autre PC c'est plutôt l'erreur comme quoi la connexion n'est pas établie qui doit s'afficher. De plus lorsque que j'installe le setup venant d'installShield je voit qu'il y'a un fichier MccDaq.ddl qui est rajouté du coup la bibliothèque est bien prise en compte, non?

[Pol63]

l'erreur a l'air de provenir de la dll MccDaq, à cause d'une mauvaise utilisation ou d'un bug dans celle ci

le stacktrace nous dit que ton form frmDataDisplay dans l'event Load appelle InitUL, qui lui appelle MccDaq.MccService.DeclareRevision qui lui apelle MccDaq.CbwApi.cbDeclareRevision qui lui plante
si le fournisseur de cette dll a fait une doc il y a peut etre l'explication de pourquoi cette erreur
à priori ta dll est codée en .net, au pire tu peux la décompiler pour chercher dans le code pourquoi il y a Throw New NullReferenceException dans cette méthode (telerik justdecompile est gratuit)


concernant l'utilisation de dll, pour une dll codée en .net, il faut qu'elle soit à côté de l'exe ou dans le GAC
pour les dll COM, celles ci doivent être registrées (regsvr32, qui fait une inscription en base de registre pour pouvoir retrouver la dll, même si elle est à côté de l'exe)

[ousmane126]

Ah d'accord merci bien pour les explications et pour justDecompiler. Pour la dll elle est bien dans le même dossier que l'exe. J'ai décompilé la dll grâce a telerik et la fonction qui semble poser problème ne renvoie que le paramètre qui a été entré en attribut. Peut être que le renvoie est un Null, c'est pour ça que le programme plante; Je vais essayé de me pencher encore plus dessus . Merci beaucoup pour ton aide

[Pol63]

System.NullReferenceException: La référence d'objet n'est pas définie à une instance d'un objet.
à MccDaq.CbwApi.cbDeclareRevision(Single& RevNum)

veut bien dire que la méthode cbDeclareRevision contient la ligne de code suivante
Throw New NullReferenceException, ou alors que cette méthode appelle une méthode dans une dll non .net qui plante éventuellement, auquel cas regardez sur le dossier créé par votre cd s'il y a d'autres dlls, auquel cas votre dll que je dis codée en .net serait un wrapper vers une dll COM qui serait peut etre manquante ... enfin c'est une hypothèse
car comme je le disais les dll COM n'ont pas besoin d'être dans le dossier de l'exe, donc ca se trouve sur votre pc de dev elle est installée et n'a pas été prise par votre générateur de setup
enfin si vous avez installé le cd sur le poste où ca plante ce que je dis doit être faux

[ousmane126]

J'ai effectivement regardé dans le dossier crée grâce au Cd et il y'a un paquet de .dll à l'intérieur et qui semblent être en relation avec la librairie MccDaq. J'ai des DaqLib.dll, Cbw.dll ,MccDaqConfig.dll,etc. Du coup peut être que ça vient de la. Le mieux c'est que je les copie dans le dossier qui contient mon fichier exe et que je relance le test,non ?

[ousmane126]

Bonjour Pol63,

J'ai enfin pu lancer mon programme sur un autre poste; le problème venait effectivement des dll qui manquaient. Il tourne bien maintenant. Merci beaucoup pour ton aide, c'est très sympa
Bonne journée

[Pol63]

tu dois voir un bouton un peu plus bas marqué "résolu" que seul le créateur du topic voit
merci de cliquer dessus

[ousmane126]

D'accord je le fais de suite. Merci encore