Cfrgtkky

I have a weird problem where standard input behaves unexpectedly while debugging in Visual Studio 2017, but only if command line arguments are present. The problem does not occur in VS2010.

As a sample, consider a Windows Application targeting .Net 3.5 with this simple code:

static class Program

{

    static void Main()

    {

        if (Console.In == null)

        {

            Console.WriteLine("Console.In: null");

        }

        else if (Console.In == StreamReader.Null)

        {

            Console.WriteLine("Console.In: " + Console.In.GetType().FullName);

        }

        else

        {

            Console.WriteLine("Console.In: " + Console.In.GetType().FullName);



            string cmd;

            while ((cmd = Console.In.ReadLine()) != null )

            {

                Thread.Sleep(1000);

            }

        }

    }

}

When debugging this in VS2010, the debug output will be "Console.In: System.IO.StreamReader+NullStreamReader" regardless of if any (dummy) command line arguments are given in the start options for the project.

When debugging the exact same code in VS2017, if there are no command line arguments given, then standard input will still be the null stream. However, if command line arguments ARE given, the output will instead be "Console.In: System.IO.TextReader+SyncTextReader", and then it will proceed to crash on ReadLine() because it's actually incapable of reading from this stream:

Exception thrown: 'System.IO.IOException' in mscorlib.dll
An unhandled exception of type 'System.IO.IOException' occurred in mscorlib.dll
Not enough storage is available to process this command.

Why does VS2017 during debugging with command line arguments present generate this unexpected standard input reader? Can I get rid of it?

Alternatively, what would be a better way to do this? (What I'm trying to do is check if there is a useful standard input because if there is the real program can read some commands from it. If there is no standard input present it should just be ignored and the rest of the program proceed in a default code path.)

Environment: Windows 7 64bit, VS2017 15.9.2. I've checked this under both .Net 3.5 and 4.0 with the same results. (.Net 4.7.2 is installed on the machine).

Update 2018-11-22

The problem occurs on my machine and also for a colleague, both on Windows 7 64-bit.

Two other colleagues run Windows 10 and for them the problem does not occur. If on Windows 10, Console.In will, as expected, be a NullStreamReader even if command line arguments are present while debugging.