Exception Directory Not Found lors du déploiement sur le serveur

Question

Le but que j'ai est simple: à partir d'une application Web, écrire dans un dossier sur le lecteur D d'un serveur local. Quand je cours le code localement (dans le débogueur) il écrit magnifiquement dans le dossier. Lorsque je publie le code sur le serveur Web, il ne peut pas voir son propre lecteur D ou dossier partagé. J'ai essayé toutes les permutations de la chaîne de chemin de fichier que je peux imaginer, y compris les absurdes.

Exemples:

filepath = "\\\\wsbliwad\\d\\Payroll\\PaperlessPay"; 
filepath = "\\wsbliwad\\d\\Payroll\\PaperlessPay"; 
filepath = "\\wsbliwad\d\Payroll\PaperlessPay"; 
filepath = "\\\\wsbliwad\\Payroll\\PaperlessPay"; 
filepath = "\\wsbliwad\Payroll\PaperlessPay"; 
filepath = @"\\wsbliwad\payroll\PaperlessPay"; 
filepath = @"\\\\wsbliwad\\payroll\\PaperlessPay"; 
filepath = @"\\wsbliwad\\payroll\\PaperlessPay"; 
filepath = @"\\wsbliwad\d\Payroll\PaperlessPay" 

... et une foule d'autres.

Utilisation des instructions Response.Write pour avoir une idée de ce qui se passe, si je lance le code localement, je reçois les commentaires suivants:

Path one = \\wsbliwad\payroll\PaperlessPay 
Exists = True 
Path two = \\wsbliwad\\payroll\\PaperlessPay 
Exists = True 
Path one = \\\\wsbliwad\\payroll\\PaperlessPay 
Exists = True 
Host Name is CPU1476 
AD User is ANVILCORP\DGray 

Et le fichier écrit dans le dossier.

Quand je déploie ce code même, je reçois un résultat d'échec:

Path one = \\wsbliwad\payroll\PaperlessPay 
Exists = False 
Path two = \\wsbliwad\\payroll\\PaperlessPay 
Exists = False 
Path one = \\\\wsbliwad\\payroll\\PaperlessPay 
Exists = False 
Host Name is WSBLIWAD 
AD User is ANVILCORP\dgray 

Aucun fichier est écrit.

Je suis allé dans le dossier et explicitement accordé des autorisations d'écriture à tous les utilisateurs de notre groupe qui en ont besoin, pensant peut-être qu'il s'agissait d'un problème d'autorisations mal rapporté. Pas de chance. Une singularité que j'ai noté est que la dernière ligne dans mon response.write me donne des lettres majuscules pour l'utilisateur de domaine quand je l'exécute dans le débogueur, et des minuscules quand le code est déployé. Je ne sais pas si cela devrait être important, mais cela semble étrange.

Des idées pour lesquelles le code peut voir le dossier partagé à partir de mon débogueur, mais pas lors du déploiement?

Pour la demande de DJ KRAZE ci-dessous:

protected void btn_Export_Click(object sender, EventArgs e) 
{ 

    DateTime mCheckDate = DateTime.Parse(tb_CheckDate.Text); 
    int mPeriod = Int32.Parse(tb_Period.Text); 


    try 
    { 
     string checkDateFormat = "MM/dd/yyyy"; 
     ReadOnlyCollection<IDataRow> dataRows = FlatFileExportWeb.PaperlessPay.GetPaperlessPayData(mPeriod.ToString(), mCheckDate.ToString(checkDateFormat)); 

     if (dataRows == null) 
      return; 

     IDataFormat format = new SimpleDataFormat(dataRows); 

     string filepath = ""; 
     string machineName = System.Net.Dns.GetHostName();    
     if (machineName == "WSBLIWAD") 
     { 
      // This path does not work 
      filepath = @"\\wsbliwad\d$\Payroll\PaperlessPay"; 
     } 
     else 
     { 
      // this path works when debugging 
      filepath = @"\\wsbliwad\payroll\PaperlessPay"; 
     } 

     string filename = "PaperlessPay" + mCheckDate.ToString("MMddyyyy") + ".txt"; 

     new FileGenerator(filepath, filename).BuildFile(format); 
     Response.Write("<br />&nbsp;&nbsp;&nbsp;Success!! The flat file has been written to " + filepath + @"\" + filename); 
    } 
    catch (Exception ex) 
    { 
     // Display any exceptions that may have been thrown. 
     System.Web.HttpContext.Current.Response.Write(ex); 
    } 
} 

... puis ...

// Absolute path with concatenated filename 
string mFilenameWithPath; 

/// <summary> 
/// Constructs a FileGenerator instance pointing to filepath\PaperlessPay\filename. 
/// Will delete pre-existing file at this location. 
/// </summary> 
public FileGenerator(string filepath, string filename) 
{ 
    if (!Directory.Exists(filepath)) 
     throw new DirectoryNotFoundException(filepath); 

    mFilenameWithPath = filepath + @"\" + filename; 

    if (File.Exists(mFilenameWithPath)) 
     File.Delete(mFilenameWithPath); 
} 


/// <summary> 
/// Given an IDataFormat instance, BuildFile builds an output string. 
/// It will then write this output string to the file specified within 
/// the class, as passed into the constructor. 
/// </summary> 
/// <param name="format"></param> 
public void BuildFile(IDataFormat format) 
{ 
    // Make sure the format exists 
    if (format == null) 
     return; 

    // Collect output string, and 
    // write the string to filepath. 
    using (StreamWriter writer = File.CreateText(mFilenameWithPath)) 
     writer.Write(format.Build()); 
} 

Answer 1

Traxs est correct. Il s'est en effet avéré être un problème d'autorisations. Nous interfaçons deux systèmes et avons créé un compte de domaine nommé Interface.Dev. Cet utilisateur était répertorié dans les propriétés de sécurité avec des autorisations d'écriture, mais pour une raison quelconque, il avait besoin de contrôle total plutôt que d'écriture.

Merci Traxs de m'avoir constamment indiqué cette voie. Le message d'erreur était TERRILEMENT trompeur, et j'aurais continué à me battre avec les informations de chemin pour une éternité autrement.

Answer 2

Avez-vous essayé

@"\\wsbliwad\d$\Payroll\PaperlessPay" 

?

Answer 3

C'est peut-être parce que vous n'avez pas accès en écriture à ce chemin.