Omnisharp-vscode: Debugger: didn't support Edit and Continue feature

[AmberZhang2016]

Environment data

dotnet --info output:
VS Code version:1.2.1
C# Extension version:1.1.7

Steps to reproduce

1. We add following code to update the value of one variable when break mode:
   a++;
2. then save the updated file;
3. F10
   

   Expected behavior

the new line will be executed and the value will be increased

Actual behavior

the new line is skipped and the value is not changed

[gregg-miskelly]

@AmberZhang2016 Edit and Continue is a large and very connected feature which we don't have any immediate plans to bring to VS Code. I will leave this open, and people feel free to '+1' this. But, just to be clear, it is at least going to be a while before we get to this.

[ghost]

@gregg-miskelly, +1

Any news?

[node-gs]

Very interested in something like this. Working from macOS with dotnet can be tough, this would really aid in the development process

[ikourfaln]

+1

[theSdev]

+1

[murr4y]

+1

Recently discovered dotnet watch with .net core. Having the same functionality with the addition of debugging would be great!

[frystpingvin]

+1

[hsinyu-chen]

+1

[JorgeGarciaIrazabal]

+1

[thorgod]

+1

[iuribrindeiro]

+1

[coumarc9]

+1

[eluchsinger]

+1

[vanmxpx]

+1

[G43beli]

+1

[blendsdk]

+1

[mohamad-xtouch]

+1

[glazjoon]

+1

[Guybrush21]

+1

[sgentile]

"But, just to be clear, it is at least going to be a while before we get to this."

2 years later... any luck :)

+2

[gregg-miskelly]

:) Not yet. But thanks for voting. The more votes the easier it will be to get funding for the project.

[amararias]

+1

[bitbonk]

We have rather complex applications that control actual machines and it is extremely time consuming (think hours!) to restart them and bring the software and the machines back into the desired state before we can try the effects that changes have to the overall system.

Of course we have unit test and integration test and all that but often it is just needed to test/try/fix things with/on the actual production hardware.

With the classic .NET Framework this is not really an option because customers might not allow the installation of a debugger on the production PC that controls the machine.

With both the .NET Core debugger and VS Code being copy-deployable, this would actually become an option and it would be extremely cool to have this ability. It would be an absolute killer feature for us.

[gregg-miskelly]

@bitbonk just as an FYI, you actually have been able to XCopy Visual Studio's remote debugger for a very long time now, in case that helps you.

[bitbonk]

@gregg-miskelly Yes I am aware of that, but last time I checked edit & continue was not possible. I'd love to be proven wrong though.

[gregg-miskelly]

I thought VS added support for remote managed EnC, but I could be remembering wrong...

[bitbonk]

@gregg-miskelly I just checked again, and you are right. Edit&Continue on classic .NET (4.7.2) does indeed work with remote debugging even if the remote debugger is launched from a remote file share. But (and that's a big but for us unfortunately) you have to launch the application with the debugger, attaching it later does not allow Edit&Continue.

I wonder if it would theoretically be possible that it could work with attaching the debugger locally to a running process in .NET Core.

[gregg-miskelly]

Technically the requirement is that the code must be Just-In-Time compiled with EnC enabled. The normal way to have that happen is to launch under a debugger. But if you don't mind giving up a bit of perf, you can run your app with the environment variable COMPLUS_ForceEnc=1 set, and then you can attach later and EnC.

[bitbonk]

Wow that‘s interesting info. I wasn’t aware of the environment variable. It seems to have some limitations though, most notably

If you make an edit after attaching you cannot detach the debugger; the debugger will terminate the process when you stop debugging

[gregg-miskelly]

To be clear - that is due to the way EnC works, not because of anything to do with the environment variable.

[clintnetwork]

It's an important feature

[Alirezanet]

+1
or i should to say +2000 for me and my partners

[kerry-perret]

exp(Important Feature!)!

[dgumberidze]

1

[clintnetwork]

Yes dotnet watch run need to be integrate to omnisharp

[Alirezanet]

every debug process takes at least about 5 minutes in medium and large applications without edit and continue so this is important feature ! i'll give this issue a BIG +1 ...

[peresbruno]

+1

[ikourfaln]

+1

[rodcoura]

+1

[Jay1305]

+1

[cloder]

+1

[clintnetwork]

+249+2-1

[olfek]

EDIT:

Ignore this solution, breakpoints don't work.

---

I found the solution to this with sheer luck

1. Stop all running dotnet processes
2. Open .vscode/launch.json
3. Change the line "preLaunchTask": "build", to "preLaunchTask": "watch",
4. Start debug mode again (F5 or in the menu: Debug -> Start Debugging)

My answer on SO

[nkev]

+1

[MESalar]

+1 Thanks

[dlkulp]

+1

[clintnetwork]

[phone]

[clintnetwork]

+0xfffffff

[tedbergeron]

+1

[nkamenar]

+1

[EmadBustati]

+1

[clintnetwork]

                            1111111   
                           1::::::1   
                          1:::::::1   
       +++++++            111:::::1   
       +:::::+               1::::1   
       +:::::+               1::::1   
 +++++++:::::+++++++         1::::1   
 +:::::::::::::::::+         1::::l   
 +:::::::::::::::::+         1::::l   
 +++++++:::::+++++++         1::::l   
       +:::::+               1::::l   
       +:::::+               1::::l   
       +++++++            111::::::111
                          1::::::::::1
                          1::::::::::1
                          111111111111

[wjsgzcn]

I found that "spring-boot-devtool" can make spring boot apps live reload in vs code.
so, I hope the dotnet sdk would support this feature instead of vs code debugger.

[Nekuskus]

+1 bois

[PauloDanielCarneiro]

Any news about this?

[XmlmXmlmX]

+100!

[TechtonicSoftware]

+1

[aintitfun]

+1

[cloder]

+1

[husseinraoouf]

i think this issue (dotnet/runtime#12409) should be fixed first

[maxiostro]

+1

[bjswart]

+1

[PauloDanielCarneiro]

Any news about this?

[PauloDanielCarneiro]

The omnishare-vscode comunicates with a omnisharp-roslyn or with the omnisharp-server?

[filipw]

omnisharp-roslyn.
omnisharp-server is legacy.

however it also has nothing to do with debugger, debugger is a separate component

[eduardonoronha]

+1

[mpriem]

+1

[artem-hryb]

+1

[Alirezaja1384]

+1