La mia applicazione si arresta in modo anomalo con FileNotFoundException e non capisco perché

Question

Ho un editor di testo che ho creato, che ha funzionato perfettamente per il mese scorso senza problemi. Ma oggi, e tutto ieri, ogni volta che apro un file txt da Explorer (doppio clic su di esso), invece di esso apertura nel mio editor, un messaggio che dice:

Editor di testo ha riscontrato un problema e deve vicino. Siamo spiacenti per questo inconveniente. [Invia segnalazione errori] o [Non inviare].

Quando clicco su "Che cosa significa questo rapporto di errore contiene", si evidenzia quanto segue:

EventType : clr20r3  P1 : texteditor.exe  P2 : 1.0.0.0  P3 : 4ad32c52  
P4 : mscorlib  P5 : 2.0.0.0  P6 : 492b834a  P7 : 343f  P8 : d8  
P9 : system.io.filenotfoundexception 

In modo che mi dice in sostanza che la sua ricerca di un file che non esiste. Ma qui è il mio problema:
Il file che sto cercando di aprire esiste perché ho appena doppio click su di esso

Qui è il codice che apre un file che è stato doppio clic su da Windows Explorer:

using System; 
using System.Collections.Generic; 
using System.Linq; 
using System.Windows.Forms; 

namespace TextEditor 
{ 
    static class Program 
    { 
     /// <summary> 
     /// The main entry point for the application. 
     /// </summary> 
     [STAThread] 
     static void Main(string[] args) 
     { 
      Application.EnableVisualStyles(); 
      Application.SetCompatibleTextRenderingDefault(false); 

      if (args.Length >= 1) 
      { 
       Form1 f = new Form1(); 
       f.txt.Text = System.IO.File.ReadAllText(args[0]); 
       f.txt.Tag = args[0]; 

       Application.Run(f); 
      } 
      else Application.Run(new Form1()); 
     } 
    } 
} 

Answer 1

Il percorso su cui si fa doppio clic su probabilmente contiene uno o più spazi, causando l'invio del percorso come più argomenti della riga di comando.

È necessario modificare l'associazione .txt per inviare il percorso tra virgolette e/o modificare l'app per leggere tutti gli argomenti della riga di comando e combinarli con gli spazi.

Explorer invia un comando come

YourApp.exe C:\Documents and Settings\YourName\My Documents\YourFile.txt 

Poiché non ci sono virgolette intorno alla stringa, viene interpretato come 4 differenti parametri separati da spazi.

È possibile modificare l'associazione per i file da .txtYourApp.exe "%1" (con il %1 tra virgolette) per forzare l'intera stringa di essere trattato come un argomento.

In alternativa, è possibile sostituire args[0] con String.Join(" ", args) per ricomporre gli argomenti.

Answer 2

Ovviamente si ha un bug: accesso al file sbagliato.

Se non è possibile eseguire il debug dell'errore su un determinato computer, scaricare e utilizzare FileMon da sysinernals e vedere a quale file si sta accedendo l'editor.

Answer 3

Il codice pubblicato non gestisce eccezioni (come FileNotFoundException) generate dal programma. Ecco perché ottieni la brutta e inutile casella "AppCrash". Come passo il debug, provare avvolgendo il codice problematico in un blocco try/catch, in questo modo:

try 
{ 
    if (args.Length >= 1) 
{ 
    // your code 
} 
catch (Exception e) 
{ 
    Console.WriteLine(e); 
} 

Questo vi dirà, almeno, il metodo che sta fallendo. Costruisci in modalità debug ed esegui dalla riga di comando con il tuo file .pdb nella stessa directory, e otterrai il numero di linea in errore.

Inoltre, provare a stampare il percorso che si sta tentando di aprire (utilizzando MessageBox o Console.WriteLine() dalla riga di comando). Potresti vedere qualcosa di strano. Sembra che tu abbia associato un tipo di file alla tua applicazione e stai facendo girare la tua app facendo doppio clic su un file. La shell potrebbe cambiare il percorso di quel file in un modo che non ti aspetti; stampare il percorso te lo dirà.

Se sei ancora bloccato, inserisci la traccia dello stack risultante. Sarebbe anche utile pubblicare un codice applicativo completo e autonomo che mostri il problema. L'esempio di codice che hai pubblicato è chiuso, ma ha una dipendenza da Form1. AU $ 10 dice che nel fare questo, avrai un momento "Eureka" e vedrai il problema.

In alternativa, se si ha accesso a un debugger (in Visual Studio), è possibile scorrere il codice finché non viene visualizzata l'eccezione generata.