Calling Directory.Exists ( “\\ server \ share \”) nel progetto di installazione

Question

Ho un progetto di installazione di .NET a cui ho aggiunto un'azione di installazione personalizzato. Durante il processo di installazione, l'utente deve fornire un percorso (che spesso è un percorso UNC) a una condivisione sul loro file server. Tento di fare un po 'di validazione prima di procedere per assicurarsi che esista la directory, come ad esempio:

if (!Directory.Exists(serverDirectory)) { 
    throw new InstallException("Specified path does not exist or ..."); 
} 

Piuttosto vaniglia - e in una console app, Directory.Exists () codice funziona come previsto. Tuttavia, nel contesto del MSI, non è così. In particolare, la chiamata a Directory.Exists fallisce sempre quando si utilizza una risorsa di rete. La documentazione per Directory.Exists non indica perché :

  

Il metodo non esegue l'autenticazione di rete esistente. Se si esegue una query di una condivisione di rete esistente senza essere pre-autenticato, il Exists metodo restituirà falso.

Ricerche mi hanno portato ad altri scenari simili in ASP.NET in cui la rappresentazione è la soluzione. Questo non è applicabile qui, ma illustra il problema.

Come posso verificare l'esistenza del percorso di rete? Per mettere nella lingua della documentazione - come faccio a preautenticare prima della chiamata? L'utente sta installando come amministratore, e la navigazione a quel percorso in Windows Explorer funziona con successo, quindi non è permessi dell'utente, ma piuttosto una mancanza di controllo da parte del codice.

ho creato una preoccupazione inutile - dovrei omettere questo e generare l'eccezione più tardi, quando si cerca di utilizzare la risorsa di rete ... è in gran parte lo stesso errore critico, a destra

?

Answer 1

Non è solo l'esistenza: è necessario controllare le autorizzazioni così, e preoccuparsi di quello che succede se cambiano su di voi nel periodo tra quando si controlla e quando effettivamente utilizzare il valore.

Quindi il meccanismo normale è di assumere solo tutto è ok. Invece, mettere il vostro sforzo di sviluppo nella gestione della eccezione quando l'ipotesi si rivela falsa, perché è necessario essere in grado di farlo con grazia in ogni caso.

Per questo caso, si potrebbe essere in grado di migliorare su questo da subito la creazione di un piccolo file segnaposto nella directory in questione, e in possesso di un blocco su quel file finché non si è completamente finito con la cartella. Ciò permetterà di dare un feedback migliore, dal momento che si otterrà un errore immediato tentativo di creare il file. Aiuta anche la garanzia che la cartella rimane accessibile, dal momento che sotto le finestre almeno gli utenti avranno un momento difficile eliminare o modificare in modo significativo la cartella fino a quando si tiene un blocco per quel file.