Fixing "Please restart your debugging session" to make a developer's life easier.

[ghost]

Last month I was writing code in C#, everything is going fine,

every time I change a lambada expression make me compile again.
every time I add the namespace make me compile again.
every time I change something in a variable (that has a breakpoint and currently pointer) make me compile again.

Most of the other thing make me compile again, This thing creeps me out, On the same side, I see developer writing the same thing in javascript doesn't need to stop and recompile.

I do a lot of recompiles to finish my work, What was I doing is consuming some API in my C# code using Restsharp and Newtonsoft.Json.

I write the same code in javascript and run it in chrome dev tool (I am not saying Javascript is good)
and debug the whole app without stop and compile.

If you are using chrome dev tool, it takes breakpoint as same as your Visual Studio editor. When you modified something it's going in the outer block. I debug my whole app without a stop at any point. This is non-stop debugging experience. I was thinking to post it in csharplang but I post it here because Roslyn is compiler and it's related to the compiler.

I have posted the same issue in https://developercommunity.visualstudio.com/content/problem/242242/the-biggest-problem-in-writing-c-code.html

if this can be improved, I believe it can help many developers. For me, I can write my code without stop and able to enjoy debugging more than ever.

[tmat]

@anirugu Thanks for feedback. This is definitely the right repository to post it. We are aware that some of the limitations, like inability to add a namespace are painful to deal with (tracked by issue #10043). We have done many improvements in this area in past, but I agree there is definitely more room for improvement.

In some cases you might be able to make the change in the code if you step out of the current block or a method. For example, making any change in a foreach statement is allowed while there is no code executing the statement but it's limited when stopped in the middle of the iteration. Restrictions like these are reported as "... around an active statement ...".

Sometimes it's simply impossible to apply an edit and keep the state of the program consistent with what would the code do if it was edited before the debugging started. For example, applying edits in lambda expressions that alter the structure of its closure such as lifting an existing local variable into the closure might require some state information that is already gone and impossible to retrieve.

Re comparison with JavaScript - I'd say JavaScript has an easier job since it's a dynamically typed language with a lot of flexibility built-in. In JavaScript the code itself can add/remove properties from objects etc. This makes it much easier to make changes while debugging.

FWIW, you can find the list of currently supported (and unsupported) edits https://github.com/dotnet/roslyn/wiki/EnC-Supported-Edits

[tmat]

Re the specific edits you mention:

• every time I change a lambada expression make me compile again.

This depends on what change is made exactly and what variables the lambda expression captures. If you can share the snippet of code and the exact error message I can check if the error is expected.

• every time I add the namespace make me compile again.

Tracked by issue #10043

• every time I change something in a variable (that has a breakpoint and currently pointer) make me compile

Can you share the code, the edit you are trying to make and the error message?

[ghost]

@tmat I was using dynamic object Deserialization, for example, https://stackoverflow.com/a/9038318/713789

I deserialize my json from string to a dynamic object. (I was meaning dynamic variable in my post).
Now after doing anything I need to come to there again and follow same thing again and again.

write the code/ debug, change the code, debug > change > debug again > change again > debug again.

If I consume same API in Javascript using chrome dev tool, I never need to stop my debugging sesison. when you modified the file, it's just go to outer part (which is good, because I just modified and debug that part, instead of stop and restart from scratch).

the chrome dev tool make the thing a lot easier for me (but I want to make API reqeust in server side c#).
If debugging experience can be simpler and similar to Chrome Dev Tool, It would make much benefit for developer.

[tmat]

@anirugu To be able to help, I'd need to see the source code of the method, where in the method was the program stopped and what change did you try to make.

[ghost]

I just mention this issue in a new issue I started today, I can't post any code here. what I was doing is consuming an API and done changed a lot during writing the code.

1. if you modify the same line where your VS execution pointing, debugging not continue.
2. just add the namespace for regex or something else, you can't continue, I mention an idea for sort out this, if namespace can be easily imported in the immediate window, it would be helpful for the developer to work effectively.

I write the same code in Javascript too in April (when I post this is dev community) and don't need to do anything, I was using jquery and consume the whole api and when I make change, debugging goes one block up and it's look good, I started from there again and able to test and debug the code that I write few second ago, this way I completely write my javascript code even without stopping at anything.

This is the experience I am talking about, a similar thing can be analyzed and better-debugging functionality can be provided in the future version of VS 2019.

[ghost]

[GSPP]

I personally notice as well that EnC is not possible in too many scenarios. EnC is extremely useful.

One particular issue that I hit very often is changes to the variables that a lambda captures.

[tmat]

General improvements tracked by #49001, specifically:

1. await: EnC: allow adding/removing await expressions in async method #54095
2. lambdas: EnC - Allow capturing new variables in lambdas #54672