Discussion :

[DonQuiche]

Tu as tout fait correctement. Je voulais savoir si c'était un bug du common language runtime et apparemment ce n'est pas le cas puisque l'on pénètre bien dans le programme. Ce serait donc un bug du programme lui-même.

Sauf que dans ce cas tu devrais avoir la fenêtre d'exception de Visual Studio et non pas la simple boîte de texte de Windows. Une erreur survenue dans une dépendance native ?

Quoi qu'il en soit il a donc falloir s'armer de patience et dérouler le programme pas à pas. Une fois le programme en pause sur la première ligne, les touches F10 et F11 permettent de survoler une ligne ou de pénétrer dans celle-ci (step over / step into). Il va falloir que tu trouves le point auquel le programme plante avant que nous ne puissions continuer. Bonne chance.

[marsouin_89]

Bonsoir,

J'ai donc essayé avec F10 et F11 mais à part me balader de ligne en ligne, je n'ai vu aucun message.
En revanche, j'ai ajouter des MessageBox afin d'identifier l'endroit bloquant.

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
16
17
18
19
public class DatasetWriter_Byte : DatasetWriter
    {
        public byte[] scanline;
 
        public DatasetWriter_Byte (string filename, int width, int height) : base(filename,width,height,1,DataType.GDT_Byte)
        {
            scanline=new byte[width];
        }
 
        public override void WriteLine(int j)
        {
            GetRasterBand(0).WriteRaster(0,j,Width,1,scanline,Width,1,0,0);
        }
 
        public override void SetPixel(int i, byte val)
        {
            scanline[i]=val;
        }
    }

A priori, çà coince entre la 1° et la 3° ligne mais je n'ai pas réussi à ajouter de MessageBox.
Comment identifier quelle ligne pose problème ?

Cordialement

Christophe

[DonQuiche]

Que veux-tu dire par 1ère et troisième ligne ? Si tu parles des numéros de lignes affichés ici, ce sont deux lignes non-exécutables, ça n'a donc pas de sens. Si tu veux dire avant le constructeur (ligne 5 : DatasetWriter_Byte), à nouveau ça n'a pas de sens.

Exécute pas-à-pas avec F10: 1 2 3... crash
Du coup tu reviens sur l'instruction 3 et là tu utilises F11 pour voir à l'itnérieur: 3.1 3.2 3.3 3.4... crash
Tu reviens sur l'instruction 3.4 tu utilises F11: 3.4.1... Etcétéra.

Tu peux aussi utiliser les breakpoints (F9) plutôt que les MessageBox. Cela te permettra de voir la pile des appels, pour voir de quelle fonction on arrive. Tu peux ensuite cliquer sur un appel parent pour voir à quel point ce code est exécuté.

Enfiin pense aussi après un crash à regarder la fenêtre de sortie (output), il y aura peut-être un message utile.

[marsouin_89]

Bonjour de ce beau matin sous la pluie,

J'avance petit à petit mais je ne désespère pas.

Je t'avoue que j'ai du mal à effectuer ce que tu me demandes, je ne constate pas plus de réaction que cela.

Cependant, j'ai réussi à trouver un problème ici :

Code :

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

1
2
3
4
5
6
7
8
9
public static void setenv()
        {
            //La variable système FWTOOLS_DIR existe ?
            string fwdir;
            fwdir = Environment.GetEnvironmentVariable("FWTOOLS_DIR");
            if (fwdir != null)
                MessageBox.Show("La variable d'environnement FWTOOLS_DIR avec le chemin du répertoire de FWTools n'existe pas.");
                return;
}

En fait la variable d'environnement existe et elle est bien lue.
Toutefois, dans l'analyse fwdir récupère bien la valeur de la variable d'environnement, mais la condition, pour vérifier si cette valeur est nulle, est considérée comme vraie.

Bizarre

Manisfestement, j'ai un autre cas de figure comme çà, mais allons y petit à petit.

Cordialement

Christophe

[DonQuiche]

Bonjour à toi.

Je t'avoue que j'ai du mal à effectuer ce que tu me demandes, je ne constate pas plus de réaction que cela.

Comment ça ? Tu veux dire que F10 et F11 ne semble pas avoir d'effet ? SI c'est le cas reprends avec un breakpoint sur la première ligne du programme (F9) : en appuyant sur F5 le programme démarre et tu es ramené à cette ligne sous VS, désormais surlignée. En appuyant sur F10 VS passe alors à la ligne suivante, surlignée à son tour. Si au lieu de F10 tu appuies sur F11 avant l'exécution d'une méthode de ton cru alors VS va pénétrer dans celle-ci.

(désolé si j'ai mal interprété et que tu trouves ces explications bateau - je ne connais pas ton expérience)

Toutefois, dans l'analyse fwdir récupère bien la valeur de la variable d'environnement, mais la condition, pour vérifier si cette valeur est nulle, est considérée comme vraie.

Bien vu, c'est un bogue. La fonction affiche le message "n'existe pas" si elle existe déjà.

Maintenant le problème est de savoir quel devrait être le bon comportement. Dans une fonction avec un nom de ce genre on s'attend à ce que l'on quitte la fonction si la variable existe déjà, pas à ce qu'on affiche un message d'erreur. Donc je mettrais celui-ci en commentaire. Cela dit ce n'est qu'une supposition, difficile d'en être sûr sans voir le reste de cette fonction.

[morgand]

Ne pas utiliser la ligne de commande fait que tu ne comprends pas ? Tu ne comprends pas quoi ? Le langage ? La compilation ? Et si tu ne connais pas les options de la ligne de commande tu vas faire "de la merde" ?

Bien sûr que non, c'est un non-sens. Connaître les arguments de la ligne de commande n'a aucun intérêt et ne fait pas de toi un meilleur programmeur, ça te fait simplement connaître les arguments utilisés en ligne de commande. Connaître le système MS build est en revanche nécessaire pour personnaliser la compilation mais seulement pour ça et ça ne te fait pas écrire un meilleur code ou concevoir de meilleures architectures. Ça fait simplement de toi quelqu'un qui sait ajouter des étapes personnalisées à la compilation, une compétence certes utile.

Je me suis mal exprimé, et je m'en excuse ... Ce n'est pas le fait de ne pas comprendre la ligne de commande, mais le fait de comprendre la compilation et ce qu'il se passe. Oui je pense, et ce n'est que mon avis, que la grande majorité des personnes ne s'intéresse pas au fonctionnement même de la compilation et de l'exécution, de ce qu'il se passe en mémoire et autres problématique lié au langage et à l'environnement. Ce qui les amènent a faire des choses bizarre. Et je pense aussi que la compréhension de la ligne de commande sur un MSBuild par exemple et un des points entrés vers cette compréhension, car comprendre certain arguments t'amène aussi à comprendre le fonctionnement sous-jacent.

C'est un avis que j'ai et n'implique que moi.

Pour ton problème, tu peux démarrer en pas à pas ce qui permet de voir exactement la ou sa bloque. Ou sinon tu peux aller dans "Debug > Exception" coché "Common Languages Runtime Exceptions", ce qui te permettra d'être arrêté par le débuger à l'endroit même ou une exception est diffusée.

Sinon donne tout ton code, on peut l'essayer chez nous et on serra dedans

[marsouin_89]

Bonsoir à tous,

désolé pour mon silence mais j'ai effectué des tas de tests dans tous les sens et j'ai finalement réussi.

En effectuant les F10 et F11, j'ai détecté une exception sur une fonction GDAL (librairies pour traitement de données géographiques).
Après de nombreuses recherches sur le Net j'ai eu ma réponse.

Finalement, j'ai réussi à compiler et tout fonctionne à merveille.
Je dois encore faire quelques tests sur d'autres PC au boulot, mais je vais devoir attendre la fin de mes vacances.
Cela dit, il n'y a pas de raison pour que cela ne fonctionne pas, je valide donc le sujet comme résolu.

Vraiment un grand merci pour votre disponibilité ainsi que tous vos conseils car avec un pauvre débutant en C# comme moi, ce n'était pas gagné.

Cordialement

Christophe