Bonjour,
J'ai sorti la première version bêta de mon appli. Un des utilisateurs a
erreur au lancement. Le problème c'est que le message d'erreur est le
suivant :
************** Texte de l'exception **************
System.NullReferenceException: La référence d'objet n'est pas définie à
instance d'un objet.
at RSSXpress.RSStreeview.getUpdateNbUnread(Int32& feedId)
at RSSXpress.RSStreeview.Init()
etc...
Le problème, c'est que ces renseignements ne me suffisent pas pour trouver
l'erreur, j'aurais besoin de connaître la ligne qui pose problème, les
valeurs des variables...
Comment faire ?
Merci
Bonjour,
J'ai sorti la première version bêta de mon appli. Un des utilisateurs a
erreur au lancement. Le problème c'est que le message d'erreur est le
suivant :
************** Texte de l'exception **************
System.NullReferenceException: La référence d'objet n'est pas définie à
instance d'un objet.
at RSSXpress.RSStreeview.getUpdateNbUnread(Int32& feedId)
at RSSXpress.RSStreeview.Init()
etc...
Le problème, c'est que ces renseignements ne me suffisent pas pour trouver
l'erreur, j'aurais besoin de connaître la ligne qui pose problème, les
valeurs des variables...
Comment faire ?
Merci
Bonjour,
J'ai sorti la première version bêta de mon appli. Un des utilisateurs a
erreur au lancement. Le problème c'est que le message d'erreur est le
suivant :
************** Texte de l'exception **************
System.NullReferenceException: La référence d'objet n'est pas définie à
instance d'un objet.
at RSSXpress.RSStreeview.getUpdateNbUnread(Int32& feedId)
at RSSXpress.RSStreeview.Init()
etc...
Le problème, c'est que ces renseignements ne me suffisent pas pour trouver
l'erreur, j'aurais besoin de connaître la ligne qui pose problème, les
valeurs des variables...
Comment faire ?
Merci
Peut-être mettre 1 On Error... au début, 1 variable incrémentée à chaque
ligne ou presque, et 1 msgbox avec la variable en cas d'erreur.
Stéphane
"Bull" a écrit dans le message de
news:
> Bonjour,
>
> J'ai sorti la première version bêta de mon appli. Un des utilisateurs a
une
> erreur au lancement. Le problème c'est que le message d'erreur est le
> suivant :
>
> ************** Texte de l'exception **************
> System.NullReferenceException: La référence d'objet n'est pas définie à
une
> instance d'un objet.
> at RSSXpress.RSStreeview.getUpdateNbUnread(Int32& feedId)
> at RSSXpress.RSStreeview.Init()
> etc...
>
> Le problème, c'est que ces renseignements ne me suffisent pas pour
> l'erreur, j'aurais besoin de connaître la ligne qui pose problème, les
> valeurs des variables...
>
> Comment faire ?
>
> Merci
>
>
Peut-être mettre 1 On Error... au début, 1 variable incrémentée à chaque
ligne ou presque, et 1 msgbox avec la variable en cas d'erreur.
Stéphane
"Bull" <bull219@wanadoo.fr> a écrit dans le message de
news:e3E7KOhWEHA.2840@TK2MSFTNGP11.phx.gbl...
> Bonjour,
>
> J'ai sorti la première version bêta de mon appli. Un des utilisateurs a
une
> erreur au lancement. Le problème c'est que le message d'erreur est le
> suivant :
>
> ************** Texte de l'exception **************
> System.NullReferenceException: La référence d'objet n'est pas définie à
une
> instance d'un objet.
> at RSSXpress.RSStreeview.getUpdateNbUnread(Int32& feedId)
> at RSSXpress.RSStreeview.Init()
> etc...
>
> Le problème, c'est que ces renseignements ne me suffisent pas pour
> l'erreur, j'aurais besoin de connaître la ligne qui pose problème, les
> valeurs des variables...
>
> Comment faire ?
>
> Merci
>
>
Peut-être mettre 1 On Error... au début, 1 variable incrémentée à chaque
ligne ou presque, et 1 msgbox avec la variable en cas d'erreur.
Stéphane
"Bull" a écrit dans le message de
news:
> Bonjour,
>
> J'ai sorti la première version bêta de mon appli. Un des utilisateurs a
une
> erreur au lancement. Le problème c'est que le message d'erreur est le
> suivant :
>
> ************** Texte de l'exception **************
> System.NullReferenceException: La référence d'objet n'est pas définie à
une
> instance d'un objet.
> at RSSXpress.RSStreeview.getUpdateNbUnread(Int32& feedId)
> at RSSXpress.RSStreeview.Init()
> etc...
>
> Le problème, c'est que ces renseignements ne me suffisent pas pour
> l'erreur, j'aurais besoin de connaître la ligne qui pose problème, les
> valeurs des variables...
>
> Comment faire ?
>
> Merci
>
>
Le problème est que par exemple dans ce cas, je dois ajouter les
lignes de code, recompiler mon appli, recréer le setup d'install,
demander à l'utilisateur de la réinstaller... Ca parait compliquer,
surtout qu'un autre bug différent m'a été signalé. Si à chaque
nouveau bug je dois recréer un fichier d'install comprenant des
msgbox pour le débugage, je ne vais pas m'en sortir.
N'y a-til pas une autre solution ?
Le problème est que par exemple dans ce cas, je dois ajouter les
lignes de code, recompiler mon appli, recréer le setup d'install,
demander à l'utilisateur de la réinstaller... Ca parait compliquer,
surtout qu'un autre bug différent m'a été signalé. Si à chaque
nouveau bug je dois recréer un fichier d'install comprenant des
msgbox pour le débugage, je ne vais pas m'en sortir.
N'y a-til pas une autre solution ?
Le problème est que par exemple dans ce cas, je dois ajouter les
lignes de code, recompiler mon appli, recréer le setup d'install,
demander à l'utilisateur de la réinstaller... Ca parait compliquer,
surtout qu'un autre bug différent m'a été signalé. Si à chaque
nouveau bug je dois recréer un fichier d'install comprenant des
msgbox pour le débugage, je ne vais pas m'en sortir.
N'y a-til pas une autre solution ?
Si, mieux définir les pré-requis d'exécution de votre application. Si
cela plante chez votre utilisateur et pas chez vous, c'est que les
contextes d'exécution sont différents et que vous n'avez pas testé le
sien ou mal vérifié dans l'application la disponibilité des ressources
nécessaires à l'exécution:
- version de Windows, version du framework,...
- composants non directement installés dans votre distribution
- données non installées avec votre application
- ressources système non nécessairement présentes chez l'utilisateur
- ...
Bull wrote:
> Le problème est que par exemple dans ce cas, je dois ajouter les
> lignes de code, recompiler mon appli, recréer le setup d'install,
> demander à l'utilisateur de la réinstaller... Ca parait compliquer,
> surtout qu'un autre bug différent m'a été signalé. Si à chaque
> nouveau bug je dois recréer un fichier d'install comprenant des
> msgbox pour le débugage, je ne vais pas m'en sortir.
> N'y a-til pas une autre solution ?
Si, mieux définir les pré-requis d'exécution de votre application. Si
cela plante chez votre utilisateur et pas chez vous, c'est que les
contextes d'exécution sont différents et que vous n'avez pas testé le
sien ou mal vérifié dans l'application la disponibilité des ressources
nécessaires à l'exécution:
- version de Windows, version du framework,...
- composants non directement installés dans votre distribution
- données non installées avec votre application
- ressources système non nécessairement présentes chez l'utilisateur
- ...
Une application destinée à une large distribution dans un environnement
non maîtrisé doit, à l'installation et / ou au démarrage, vérifier que
toutes les ressources nécessaires à l'exécution sont disponibles.
Une bonne manière d'éliminer un maximum de ces problèmes est de tester
votre application sur des configurations diverses et sur une machine
différente de la machine de développement et bien sûr avec des droits
utilisateurs différents. Ce n'est pas chose facile mais aujourd'hui,
vouloir distribuer une application grand public requiert un minimum
d'infrastructure en termes de tests.
Sinon, insérez une bonne fois pour toute du code de journalisation dans
votre appli, ce code n'étant activé que dans la version beta ou dans un
mode spécial activable par l'utilisateur. Bien sûr, c'est ennuyeux à
faire mais il faut bien mettre en place les moyens techniques
nécessaires au déboage de votre code.
Utilisez également les exceptions structurées (try / catch) de manière
systématique dans votre code afin de récupérer vous même les exceptions
au lieu de laisser le gestionnaire d'exception par défaut traiter le
problème (et terminer votre appli).
Si vous avez l'intention de distribuer une application destinée à
tourner sur un grand nombre de configurations très différentes, il faut
que votre code soit préparé à toute éventualité. Il ne faut jamais
supposer quoi que ce soit concernant la disponibilité d'une ressource
critique.
Vous pourrez toujours arriver à repérer une erreur particulière mais,
comme vous le disiez, au prochain bug vous allez recommencer. Autant
prendre d'entrée de jeu les mesures nécessaires.
Bon courage.
PS: la ligne qui pose problème est bien la dernière citée par le
gestionnaire d'exception. L'erreur n'est pas loin de cette ligne. En
l'occurence il s'agit de l'utilisation d'une référence non initialisée:
votre argument "feedId" est bien initialisé dans tous les cas? Le
vérifiez vous?
--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.fr
Si, mieux définir les pré-requis d'exécution de votre application. Si
cela plante chez votre utilisateur et pas chez vous, c'est que les
contextes d'exécution sont différents et que vous n'avez pas testé le
sien ou mal vérifié dans l'application la disponibilité des ressources
nécessaires à l'exécution:
- version de Windows, version du framework,...
- composants non directement installés dans votre distribution
- données non installées avec votre application
- ressources système non nécessairement présentes chez l'utilisateur
- ...
Bull wrote:
> Le problème est que par exemple dans ce cas, je dois ajouter les
> lignes de code, recompiler mon appli, recréer le setup d'install,
> demander à l'utilisateur de la réinstaller... Ca parait compliquer,
> surtout qu'un autre bug différent m'a été signalé. Si à chaque
> nouveau bug je dois recréer un fichier d'install comprenant des
> msgbox pour le débugage, je ne vais pas m'en sortir.
> N'y a-til pas une autre solution ?
Si, mieux définir les pré-requis d'exécution de votre application. Si
cela plante chez votre utilisateur et pas chez vous, c'est que les
contextes d'exécution sont différents et que vous n'avez pas testé le
sien ou mal vérifié dans l'application la disponibilité des ressources
nécessaires à l'exécution:
- version de Windows, version du framework,...
- composants non directement installés dans votre distribution
- données non installées avec votre application
- ressources système non nécessairement présentes chez l'utilisateur
- ...
Une application destinée à une large distribution dans un environnement
non maîtrisé doit, à l'installation et / ou au démarrage, vérifier que
toutes les ressources nécessaires à l'exécution sont disponibles.
Une bonne manière d'éliminer un maximum de ces problèmes est de tester
votre application sur des configurations diverses et sur une machine
différente de la machine de développement et bien sûr avec des droits
utilisateurs différents. Ce n'est pas chose facile mais aujourd'hui,
vouloir distribuer une application grand public requiert un minimum
d'infrastructure en termes de tests.
Sinon, insérez une bonne fois pour toute du code de journalisation dans
votre appli, ce code n'étant activé que dans la version beta ou dans un
mode spécial activable par l'utilisateur. Bien sûr, c'est ennuyeux à
faire mais il faut bien mettre en place les moyens techniques
nécessaires au déboage de votre code.
Utilisez également les exceptions structurées (try / catch) de manière
systématique dans votre code afin de récupérer vous même les exceptions
au lieu de laisser le gestionnaire d'exception par défaut traiter le
problème (et terminer votre appli).
Si vous avez l'intention de distribuer une application destinée à
tourner sur un grand nombre de configurations très différentes, il faut
que votre code soit préparé à toute éventualité. Il ne faut jamais
supposer quoi que ce soit concernant la disponibilité d'une ressource
critique.
Vous pourrez toujours arriver à repérer une erreur particulière mais,
comme vous le disiez, au prochain bug vous allez recommencer. Autant
prendre d'entrée de jeu les mesures nécessaires.
Bon courage.
PS: la ligne qui pose problème est bien la dernière citée par le
gestionnaire d'exception. L'erreur n'est pas loin de cette ligne. En
l'occurence il s'agit de l'utilisation d'une référence non initialisée:
votre argument "feedId" est bien initialisé dans tous les cas? Le
vérifiez vous?
--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.fr
Si, mieux définir les pré-requis d'exécution de votre application. Si
cela plante chez votre utilisateur et pas chez vous, c'est que les
contextes d'exécution sont différents et que vous n'avez pas testé le
sien ou mal vérifié dans l'application la disponibilité des ressources
nécessaires à l'exécution:
- version de Windows, version du framework,...
- composants non directement installés dans votre distribution
- données non installées avec votre application
- ressources système non nécessairement présentes chez l'utilisateur
- ...
Bull wrote:
> Le problème est que par exemple dans ce cas, je dois ajouter les
> lignes de code, recompiler mon appli, recréer le setup d'install,
> demander à l'utilisateur de la réinstaller... Ca parait compliquer,
> surtout qu'un autre bug différent m'a été signalé. Si à chaque
> nouveau bug je dois recréer un fichier d'install comprenant des
> msgbox pour le débugage, je ne vais pas m'en sortir.
> N'y a-til pas une autre solution ?
Si, mieux définir les pré-requis d'exécution de votre application. Si
cela plante chez votre utilisateur et pas chez vous, c'est que les
contextes d'exécution sont différents et que vous n'avez pas testé le
sien ou mal vérifié dans l'application la disponibilité des ressources
nécessaires à l'exécution:
- version de Windows, version du framework,...
- composants non directement installés dans votre distribution
- données non installées avec votre application
- ressources système non nécessairement présentes chez l'utilisateur
- ...
Une application destinée à une large distribution dans un environnement
non maîtrisé doit, à l'installation et / ou au démarrage, vérifier que
toutes les ressources nécessaires à l'exécution sont disponibles.
Une bonne manière d'éliminer un maximum de ces problèmes est de tester
votre application sur des configurations diverses et sur une machine
différente de la machine de développement et bien sûr avec des droits
utilisateurs différents. Ce n'est pas chose facile mais aujourd'hui,
vouloir distribuer une application grand public requiert un minimum
d'infrastructure en termes de tests.
Sinon, insérez une bonne fois pour toute du code de journalisation dans
votre appli, ce code n'étant activé que dans la version beta ou dans un
mode spécial activable par l'utilisateur. Bien sûr, c'est ennuyeux à
faire mais il faut bien mettre en place les moyens techniques
nécessaires au déboage de votre code.
Utilisez également les exceptions structurées (try / catch) de manière
systématique dans votre code afin de récupérer vous même les exceptions
au lieu de laisser le gestionnaire d'exception par défaut traiter le
problème (et terminer votre appli).
Si vous avez l'intention de distribuer une application destinée à
tourner sur un grand nombre de configurations très différentes, il faut
que votre code soit préparé à toute éventualité. Il ne faut jamais
supposer quoi que ce soit concernant la disponibilité d'une ressource
critique.
Vous pourrez toujours arriver à repérer une erreur particulière mais,
comme vous le disiez, au prochain bug vous allez recommencer. Autant
prendre d'entrée de jeu les mesures nécessaires.
Bon courage.
PS: la ligne qui pose problème est bien la dernière citée par le
gestionnaire d'exception. L'erreur n'est pas loin de cette ligne. En
l'occurence il s'agit de l'utilisation d'une référence non initialisée:
votre argument "feedId" est bien initialisé dans tous les cas? Le
vérifiez vous?
--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.fr
Que dois-je faire concrètement ? Voir toutes références de mon projet
et change la propriété "copie locale" à vrai de façon à ce que
l'utilisateur ait cette dll de copiée ?
Que dois-je faire concrètement ? Voir toutes références de mon projet
et change la propriété "copie locale" à vrai de façon à ce que
l'utilisateur ait cette dll de copiée ?
Que dois-je faire concrètement ? Voir toutes références de mon projet
et change la propriété "copie locale" à vrai de façon à ce que
l'utilisateur ait cette dll de copiée ?
Bull wrote:
> Que dois-je faire concrètement ? Voir toutes références de mon projet
> et change la propriété "copie locale" à vrai de façon à ce que
> l'utilisateur ait cette dll de copiée ?
Non, je ne parle pas de cela. Prenons un exemple simple. Si votre
programme se connecte sur une base de données à l'aide d'un provider ADO
.Net, il faut que vous soyiez sûr que
1. La BD est accessible depuis le poste utilisateur (droits d'accès,
accès au serveur, etc...)
2. Le provider en question est installé sur la machine utilisateur.
C'est cela que je veux dire quand je parle de vérifier que les
ressources dont a besoin le programme sont disponibles. Cela doit faire
partie intégrante de votre application.
En un mot, ne jamais supposer que l'utilisateur utilisera votre
application dans le même environnement que vous. Ne jamais supposer que
puisque cela fonctionne sous Win2K chez vous, cela fonctionnera sous XP
chez les autres. Par exemple, les permissions par défaut concernant les
répertoires ne sont pas les mêmes sous Win2K et sous XP. Sous XP vous
devez stocker les données du programme dans le répertoire Application
Data de l'utilisateur, pas dans le répertoire de l'application. Ce n'est
qu'un exemple.
Ce que vous avez à faire concrètement est donc une analyse approfondie
de votre code en vous assurant qu'à chaque fois que votre programme
accède à une ressource, vous avez prévu le cas où cette ressource ne
serait pas présente chez l'utilisateur, qu'à chaque fois que vous
supposez avoir un droit d'accès sur un fichier particulier, vous avez
vérifié que votre utilisateur aura à coup sûr les mêmes droits, quel que
soit le système qu'il utilise, etc. Ce type de problème peut en général
se détecter en tournant l'appli sous un compte qui n'est pas un compte
administrateur. Et en évitant de développer sous des comptes
administrateur.
--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.fr
Bull wrote:
> Que dois-je faire concrètement ? Voir toutes références de mon projet
> et change la propriété "copie locale" à vrai de façon à ce que
> l'utilisateur ait cette dll de copiée ?
Non, je ne parle pas de cela. Prenons un exemple simple. Si votre
programme se connecte sur une base de données à l'aide d'un provider ADO
.Net, il faut que vous soyiez sûr que
1. La BD est accessible depuis le poste utilisateur (droits d'accès,
accès au serveur, etc...)
2. Le provider en question est installé sur la machine utilisateur.
C'est cela que je veux dire quand je parle de vérifier que les
ressources dont a besoin le programme sont disponibles. Cela doit faire
partie intégrante de votre application.
En un mot, ne jamais supposer que l'utilisateur utilisera votre
application dans le même environnement que vous. Ne jamais supposer que
puisque cela fonctionne sous Win2K chez vous, cela fonctionnera sous XP
chez les autres. Par exemple, les permissions par défaut concernant les
répertoires ne sont pas les mêmes sous Win2K et sous XP. Sous XP vous
devez stocker les données du programme dans le répertoire Application
Data de l'utilisateur, pas dans le répertoire de l'application. Ce n'est
qu'un exemple.
Ce que vous avez à faire concrètement est donc une analyse approfondie
de votre code en vous assurant qu'à chaque fois que votre programme
accède à une ressource, vous avez prévu le cas où cette ressource ne
serait pas présente chez l'utilisateur, qu'à chaque fois que vous
supposez avoir un droit d'accès sur un fichier particulier, vous avez
vérifié que votre utilisateur aura à coup sûr les mêmes droits, quel que
soit le système qu'il utilise, etc. Ce type de problème peut en général
se détecter en tournant l'appli sous un compte qui n'est pas un compte
administrateur. Et en évitant de développer sous des comptes
administrateur.
--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.fr
Bull wrote:
> Que dois-je faire concrètement ? Voir toutes références de mon projet
> et change la propriété "copie locale" à vrai de façon à ce que
> l'utilisateur ait cette dll de copiée ?
Non, je ne parle pas de cela. Prenons un exemple simple. Si votre
programme se connecte sur une base de données à l'aide d'un provider ADO
.Net, il faut que vous soyiez sûr que
1. La BD est accessible depuis le poste utilisateur (droits d'accès,
accès au serveur, etc...)
2. Le provider en question est installé sur la machine utilisateur.
C'est cela que je veux dire quand je parle de vérifier que les
ressources dont a besoin le programme sont disponibles. Cela doit faire
partie intégrante de votre application.
En un mot, ne jamais supposer que l'utilisateur utilisera votre
application dans le même environnement que vous. Ne jamais supposer que
puisque cela fonctionne sous Win2K chez vous, cela fonctionnera sous XP
chez les autres. Par exemple, les permissions par défaut concernant les
répertoires ne sont pas les mêmes sous Win2K et sous XP. Sous XP vous
devez stocker les données du programme dans le répertoire Application
Data de l'utilisateur, pas dans le répertoire de l'application. Ce n'est
qu'un exemple.
Ce que vous avez à faire concrètement est donc une analyse approfondie
de votre code en vous assurant qu'à chaque fois que votre programme
accède à une ressource, vous avez prévu le cas où cette ressource ne
serait pas présente chez l'utilisateur, qu'à chaque fois que vous
supposez avoir un droit d'accès sur un fichier particulier, vous avez
vérifié que votre utilisateur aura à coup sûr les mêmes droits, quel que
soit le système qu'il utilise, etc. Ce type de problème peut en général
se détecter en tournant l'appli sous un compte qui n'est pas un compte
administrateur. Et en évitant de développer sous des comptes
administrateur.
--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.fr
Merci beaucoup pour toutes ces infos.
Je ne sais pas si j'utilise l'ado.net, pour mes connections j'utilise
cet objet :
Dim connection As System.Data.OleDb.OleDbConnection = New
System.Data.OleDb.OleDbConnection
Merci beaucoup pour toutes ces infos.
Je ne sais pas si j'utilise l'ado.net, pour mes connections j'utilise
cet objet :
Dim connection As System.Data.OleDb.OleDbConnection = New
System.Data.OleDb.OleDbConnection
Merci beaucoup pour toutes ces infos.
Je ne sais pas si j'utilise l'ado.net, pour mes connections j'utilise
cet objet :
Dim connection As System.Data.OleDb.OleDbConnection = New
System.Data.OleDb.OleDbConnection
> Un doute brutal m'assaille: le framework .Net est bien installé sur la
machine de l'utilisateur en question?
Si oui, le provider ADO .Net pour OleDb est présent. Par contre,
certains paramètres de la chaîne de connexion peuvent être inadéquats
sur cette machine. OLE DB utilise lui même ses propres providers? Quel
provider OleDB (ADO) utilisez vous (en clair, quel type de base de
données utilisez vous)? Êtes vous sûr qu'il est présent sur la machine
utilisateur?
> Un doute brutal m'assaille: le framework .Net est bien installé sur la
machine de l'utilisateur en question?
Si oui, le provider ADO .Net pour OleDb est présent. Par contre,
certains paramètres de la chaîne de connexion peuvent être inadéquats
sur cette machine. OLE DB utilise lui même ses propres providers? Quel
provider OleDB (ADO) utilisez vous (en clair, quel type de base de
données utilisez vous)? Êtes vous sûr qu'il est présent sur la machine
utilisateur?
> Un doute brutal m'assaille: le framework .Net est bien installé sur la
machine de l'utilisateur en question?
Si oui, le provider ADO .Net pour OleDb est présent. Par contre,
certains paramètres de la chaîne de connexion peuvent être inadéquats
sur cette machine. OLE DB utilise lui même ses propres providers? Quel
provider OleDB (ADO) utilisez vous (en clair, quel type de base de
données utilisez vous)? Êtes vous sûr qu'il est présent sur la machine
utilisateur?
Vous pourriez nous faire voir votre chaîne de connexion?
--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.fr
Vous pourriez nous faire voir votre chaîne de connexion?
--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.fr
Vous pourriez nous faire voir votre chaîne de connexion?
--
Patrick Philippot - Microsoft MVP [.Net]
MainSoft Consulting Services
www.mainsoft.fr
