Domanda

Ho un'applicazione C # che include il seguente codice:

string file = "relativePath.txt";

//Time elapses...

string contents = File.ReadAllText(file);

Funziona bene, il più delle volte. Il file viene letto in relazione alla directory da cui è stata avviata l'app. Tuttavia, durante i test, è stato scoperto che se lasciata sola per circa 5 ore, l'app genererà un FileNotFoundException dicendo che " C: \ Documents and Settings \ Adminstrator \ relativePath.txt " non può essere trovato. Se l'azione che legge il file viene eseguita immediatamente, il file viene letto dalla posizione corretta, che chiameremo " C: \ foo \ relativePath.txt "

Cosa dà? E qual è la soluzione migliore? Risoluzione del file con Assembly.GetEntryAssembly (). Posizione ?

È stato utile?

Soluzione

Se il file si trova sempre in un percorso relativo all'assembly eseguibile, quindi sì, utilizzare Assembly.Location. Uso principalmente Assembly.GetExecutingAssembly, se applicabile, invece di Assembly.GetEntryAssembly. Ciò significa che se si accede al file da una DLL, il percorso sarà relativo al percorso DLL.

Altri suggerimenti

Un posto spettrale che può cambiare il tuo percorso è OpenFileDialog. Mentre un utente naviga tra le cartelle, sta cambiando la directory dell'applicazione con quella attualmente in fase di visualizzazione. Se l'utente chiude la finestra di dialogo in una directory diversa, rimarrai bloccato in quella directory.

Ha una proprietà chiamata RestoreDirectory che fa reimpostare il percorso nella finestra di dialogo. Ma credo che il valore predefinito sia "false".

Penso che la lezione dovrebbe essere non fare affidamento su percorsi relativi, sono inclini a errori. La directory corrente può essere cambiata da qualsiasi numero di cose nel processo in esecuzione come le finestre di dialogo dei file (anche se esiste una proprietà per impedire loro di cambiarla), quindi non puoi mai davvero garantire dove un percorso relativo porterà sempre in qualsiasi momento a meno che tu non usi il percorso relativo per generarne uno fisso da un percorso noto come Application.StartupPath (anche se attenzione quando si avvia da Visual Studio) o qualche altro percorso noto.

L'uso di percorsi relativi renderà difficile mantenere il codice poiché un cambiamento in una parte totalmente non correlata del progetto potrebbe causare il fallimento di un'altra parte.

In System.Environment, hai la SpecialFolder enum, che ti aiuterà a ottenere percorsi relativi standard.

In questo modo, almeno, il percorso viene ottenuto internamente e ti viene restituito, quindi si spera che se il sistema sta cambiando il percorso in qualche modo, il codice lo gestirà semplicemente.

se fai qualcosa come

> cd c: \ cartella 1

c: \ cartella 1 > ../folder 2 / theApplication.exe

L'attuale directory di lavoro dell'applicazione sarà c: \ cartella 1.

Ecco un esempio di programma

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

namespace CWD {
    class Program {
        static void Main (string[] args) {
            Console.WriteLine(Application.StartupPath);
        }
    }
}

Crea questo in visualstudio, quindi apri un prompt dei comandi nella directory debug / bin ed esegui

bin / debug > CWD.exe

quindi

bin / debug > cd ../../ & Gt; bin / debug / CWD.exe

vedrai la differenza nel percorso di avvio.

In relazione alla domanda originale ... " se lasciato solo per circa 5 ore, l'app genererà un FileNotFoundException "

Quando l'applicazione è in esecuzione, solo lo spostamento o la rimozione di quel file dalla posizione prevista dovrebbe causare questo errore.

Greg

Se usi un openfiledialog e la proprietà Remember Path (non sei sicuro del nome esatto) è vera, penso che cambierà la tua directory attuale.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top