var actual = Path.Combine("c:", "filename");
var expected = @"c:\filename";
Assert.AreEqual(expected, actual);
RésultatPourquoi Path.Combine n'ajoute pas Path.DirectorySeparatorChar après le désignateur de lecteur?
{Assert.AreEqual failed. Expected:<c:\filename>. Actual:<c:filename>.
Pourquoi?
C:filename est un chemin d'accès valide et est différent de C:\filename. C:filename est le fichier filename dans le répertoire en cours sur le lecteur C: tandis que C:\filename est le fichier filename à la racine de ce lecteur. Apparemment, ils voulaient garder la fonctionnalité de référencement dans le répertoire en cours sur un lecteur.
Ce comportement est décrit dans here MSDN
MSDN ne semble pas expliquer pourquoi, mais elle fournit de la documentation sur ce que vous voyez:
Path.Combine (string chemin1, string path2)
Si chemin1 est pas un lecteur référence (c'est-à-dire "C:" ou "D:") et ne se termine pas par un caractère séparateur valide tel que défini dans DirectorySeparatorChar, AltDirectorySeparatorChar ou VolumeSeparatorChar, DirectorySeparatorChar est ajouté à path1 avant la concaténation.
Ceci est une mise en réserve de IIRC 1.x DOS ... :-) –
Freaky ... c'est unintuitive. Quel est le moyen d'obtenir la valeur attendue? 'Path.Combine (lecteur + @" \ ", chemin)'? – Gishu
@Gishu - Ce n'est pas intuitif, car la façon dont les chemins fonctionnent dans le système d'exploitation Windows n'est pas aussi simple qu'on pourrait le penser. Voir l'article MSDN auquel je suis lié pour trouver une description du fonctionnement des chemins Windows. Path.Combine() combine deux chemins. Je n'utiliserais pas la concaténation de chaînes de la manière que vous suggérez, car cela va à l'encontre du but de Path.Combine(). AFAIC vous devriez être prudent dans la façon dont vous spécifiez vos chemins. Si vous voulez dire "C: \" utilisez cela, si OTOH vous voulez dire "C:" (ce qui est différent mais tout aussi valide), utilisez-le. –