1

I'm initializing a System.IO.StreamReader by passing a string which contains a UNC Path, but the StreamReader ctor is prefixing the UNC path with the working directory, resulting in a System.IO.DirectoryNotFoundException.

The UNC path is stored in applicationSettings, with value:

‪    \\networkShareMachine\Projects\hold\tst.csv

I'm getting the UNC from applicationSettings using this:


    public static object GetValue(string settingName)
        {
            object result = null;
            Configuration config = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);

            // find section
            ClientSettingsSection configSection = config.SectionGroups[@"applicationSettings"].Sections["VCM.WPF.Properties.Settings"] as ClientSettingsSection;

            var setting = configSection.Settings.Get(settingName).Value.ValueXml.InnerText;

            result = setting;
            return result;
        }
    }

Intellisense tells me the value of the "setting" variable is correct, except with doubled-up backslashes:

    string setting = (string)Utils.SettingsReader.GetValue("CSVLocation");

    \\\\networkShareMachine\\Projects\\hold\\tst.csv

Then, I new up a StreamReader by passing the UNC value into the ctor:


    using (var streamReader = new StreamReader(path: setting))
    {
        ...
    }

I expect the stream reader to be initialized just like any other time, except I'm getting a

System.IO.DirectoryNotFoundException.

The reason why is because the UNC is being prefixed with the working directory like so:

'C:\Users\userName\source\repos\VCM\VCM.Models.Test\bin\Debug\‪\networkMachineName\Projects\hold\tst.csv'

It seems like the StreamReader ctor is prefixing the string itself. Why is it doing this and how can I prevent it?

Methistemi
  • 35
  • 6
  • 2
    I don't think it is likely that StreamReader is doing anything to your path. People use UNC paths all the time with `FileStream` and `StreamReader` just constructs a `FileStream` with the unmodified path. I think it is more likely that you have a problem with your path, such as an invisible character in it. Can you make a minimally reproducible example? – Dark Falcon May 20 '19 at 23:24
  • 2
    You can prove that StreamReader isn't doing it itself by just hardcoding the path you pass on instantiation for testing. – itsme86 May 20 '19 at 23:27
  • I agree it's extremely unlikely that the StreamReader is in any way manipulating the input string. I only intended to identify the point where the string change appears to happen. I did try passing in a hardcoded string and it worked fine. Therefore I think the problem has to do with how StreamReader is interpreting the string. Why would it think I'm asking for a relative path? – Methistemi May 21 '19 at 00:41
  • 1
    If the path does not begin with `"\\"` or a drive letter (on Windows) it appears to treat it as a relative path. Does `using (var streamReader = new StreamReader(setting.Trim()))` work? Is the value of `setting[0]` something other than `'\'`? Inspecting `setting.ToCharArray()` in the debugger is another way to verify the string really contains only the characters it appears to. – Lance U. Matthews May 21 '19 at 01:12

1 Answers1

1

Can I suggest checking your UNC path with Path.IsPathRooted to see if .NET actually agrees it's an absolute path? If it's not, try looking for "invisible" extra characters at the start of the string.

Like a 'tab' maybe?

Roger Willcocks
  • 1,649
  • 13
  • 27
  • I used Path.IsPathRooted and it turned out it wasn't. I used setting.ToCharArray() and found that there was an 8234 at the start of the string, which I think is a quote. I checked the settings file again, and there was no quote. I used every visualizer the debug had, and there was no quote. Very strange. Thanks for showing me that useful function. – Methistemi May 21 '19 at 03:41
  • @Methistemi Glad it helped. 8234 is a Unicode marker for "Left-To-Right Embedding" Is your default language for that file a "Right-to-Left" one? – Roger Willcocks May 21 '19 at 21:51
  • No, it's just the settings file generated by the settings designer in VS17. [Here's a gist of it](https://gist.github.com/JL-100/d817bbc0f67555460f76922ed0a9a694). I ended up using a regex to remove the invisible character. – Methistemi May 22 '19 at 03:22
  • @Methistemi Let's blame copy/paste then :) – Roger Willcocks May 22 '19 at 03:30