|
|
After some more testing I found that the URIBuilder class does not work correctly with UNC path. Here's the updated code:
public static string PathToFileUrl( string pathToConvert )
{ string fileURL = "";
bool isUNC;
UriBuilder fileURI = null;
// This is to capture whether the incoming path is
// an UNC path or not.
if ( pathToConvert.StartsWith( @"\\" ) )
{ isUNC = true;
}
else
{ isUNC = false;
}
try
{ fileURI = new UriBuilder( pathToConvert );
}
catch( UriFormatException ex )
{ // This is for debugging
string msg = ex.Message;
}
if ( isUNC )
{ if ( fileURI != null ) fileURL = fileURI.ToString();
}
else
{ if ( fileURI != null ) fileURL = fileURI.ToString().Replace( "file://", "file:///" );
}
return fileURL;
}
Previous Page | Next Page
COMMENTS
Isn't the Replace for the file:// required for both case? E.g. UriBuilder("\\foo\bar").ToString() and UrilBuilder("c:\foo\bar").ToString() seem to return "file://foo/bar" and "file://C:/foo/bar" in PowerShell.
That's what I thought too. Apparently, UNC paths and drive paths get treated differently by UriBuilder. I noticed this after I got done testing UNC paths and went back to drive paths for testing.
I want to look at UriBuilder with Reflector when I have time.
Your first example, UriBuilder("\\foo\bar"), would throw an exception, unless "foo" is a host name accessible in your LAN.
Well, this is the PowerShell command line I used:
$(New-Object System.UriBuilder("\\foo\bar")).ToString()
And there's no accessible foo hostname on my lan. Maybe this is some PowerShell thing...
Interesting! That blows up in Visual Studio.
