Console.ReadLine() is not supported

[zxyao145]

Hi, I'm I'm trying to use try.net, I found that Console.ReadLine() cannot be used, So can I use it later? I hope try.net can be more perfect, thanks very much!

[briangithex]

Supporting Console.ReadLine() would require try.net to leave a running instance of the application running on their server, awaiting I/O. I don't think this feature is likely.

[jonsequitur]

@briangithex This is exactly right ... for the server-side execution model. But we've been shifting code execution to the browser using Blazor, and we hope to revisit this.

[jimbobbennett]

Would love to have support for this for porting intro to C# courses. A lot use ReadLine for more advanced "hello world" scenarios. Some kind of virtual console they could type into would be amazing.

[BillWagner]

@jimbobbennett I've found that by re-thinking the tutorial code somewhat, I can avoid the use of Console.Readline. It may make this less important.

I'm also experimenting with more advanced tutorials where I use a data file (JSON, CSV, whatever...) and have readers open VSCode to modify input. There's a clunkiness there, but it opens a lot of possibilities.

[jonsequitur]

We do want to add support for this in dotnet try. See #230.

[HEskandari]

We want to adopt dotnet try in our NServiceBus samples. It basically requires 'endpoints' to run until stopped, which in a console app is achieved by a Console.ReadLine().

[alexyvic]

Tried it today and this feature still not supported.

[RaphaelTetreault]

I am currently working on interactive materials to help teach C# to undergraduate game design students. Try .NET seems like it could be the best candidate for integration in our Learning Management System, but there is a user experience hurdle that is dissuading me from adopting it. Namely, while Console.ReadLine() works, it does not work as one would expect.

When the program reaches a Console.ReadLine() call, a browser pop-up asks for user input, but after sending input with a press of the enter key, the browser creates another input window and does not continue executing the code from the window-triggering ReadLine call. The user must hit the escape key to stop input, then the program continues running.

More confusingly, if the user inputs text 5 separate times (pressing the enter key to send input to Try .NET), these appear to be saved in a queue/buffer which ReadLine pulls from each time it is called in the program. This means a program with a single ReadLine will read the first entry in the queue, with any remaining input still in the queue. The program can finish, then a subsequent run of the program will not prompt the user for input but instead read directly from the queue. This becomes very confusing if the user accidentally inputs something multiple times as the program will not ask for input. In cases where programs have multiple ReadLine calls, the issue is more unintuitive as subsequent calls read input from a previous user context.

In essence, the issue I see is Try .NET's Console.ReadLine() handling does not reflect the same user experience one has with a console program offline. For myself, this is a deal breaker as we are teaching students to make interactive software. The current input handling does not satisfy that needs of an interactive console program. I wish it would, since otherwise it is quite good.

The browser's I tested in include:

• FireFox: 110.0.1 (64-bit)
• Chrome: 110.0.5481.104 (Official Build) (64-bit)

[jonsequitur]

There are a number of known limitations with Try .NET for education scenarios. It's really oriented more towards documentation.

Have you taken a look at Polyglot Notebooks?

(Console.ReadLine also doesn't work there, for different reasons, but in the meantime it does support user input gestures.)

[Adam-wil]

I would love some movement on Console.ReadLine() becoming available in Try . NET.

[theonewolf]

This would really be helpful also for experiments with string encodings directly in the web browser.