Roslyn: EnC: Disable editor warning "changes made in project will not be applied while the application is running"

[vsfeedback]

_This issue has been moved from a ticket on Developer Community._

---

Please do not show this warning if _Enable Edit and Continue_ is disabled. The developer knows that the changes don't match with the current running application and the decorated source code is distracting.

---

Original Comments

Visual Studio Feedback System on 9/28/2019, 08:23 PM:

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

oa on 10/1/2019, 04:25 AM:

btw: Tools->Options->Fonts and Colors->Stale Code has no impact on the color of the drawn lines

Doug Meeker on 10/3/2019, 09:18 AM:

It looks like Other Error is the one with default set to purple squiggles. But that does not effect this error display either.

Visual Studio Feedback System on 10/3/2019, 02:31 PM:

This issue is currently being investigated. Our team will get back to you if either more information is needed, a workaround is available, or the issue is resolved.

---

Original Solutions

(no solutions)

[QuantumToasted]

I suspect commit e8a7d91cc01b8904a876b362598a468337c169e7 may be related to this issue or its cause, as I have been experiencing this since around the time this was committed. It is quite the annoyance for all edits to get this purple lint when making edits while testing, especially since I turned Edit and Continue off to avoid needing to know my running code is out of date. Will try testing on earlier commits than this one to see if there are any results.

Edit: I reverted to the commit before this one to see if it was responsible and from my testing did not prove anything one way or another. With EnC disabled the issue persisted - code was still marked saying that changes would not be applied.

[tmat]

@QuantumToasted We will definitely address this issue. That said, I am curious why you disable EnC. Do you often need to make edits that can't be applied?

[QuantumToasted]

It might just be the types of projects I work on or how I work on them. I will normally develop until point A, have myself and others test progress to point A while i am working to point B, then repeat the process for points C, D, etc. It saves needing to build or deploy my project for testing and debugging while I work. I can run a debugging session on my current project while also continuing work on it past what I have done up until that point.

Of course, all of this is done under the assumption that EnC works the way it did when I started development over a year ago. Previously, having EnC enabled meant I could not make any code changes while debugging. If I wanted to continue development work I would need to stop the current debugging session. Somewhere in the ballpark of a month ago it started adding this ENC1003 warning to code I added while debugging. It has never done that before until this point which caused the suspicions about certain commits being to blame. It doesn't prevent me from working, but it is surely can be an eyesore to people like myself who try to keep their code lint-free.

[tmat]

Yes, we indeed changed the way how EnC works. We will no longer block you to make any changes while the app is running when EnC is on. We will report a warning that these changes are not reflected in the running app however, to avoid confusion on why breakpoints might not be hit or Watch window shows stale results. The changes will be applied once the app hits a breakpoint and then resumes running, provided that all the changes are allowed updates.

[QuantumToasted]

That's good to know at least. I do not think the warning is pointless as what it conveys is certainly useful information, but a situation or option to disable them for users who develop in a way such as the one I stated earlier would be nice. It can just be distracting while trying to find actual syntax errors in the code you're currently writing, especially while using other development assistant tools such as ReSharper.

[tmat]

@QuantumToasted If we provided an option to suppress this warning would you still prefer to work with EnC turned off?

[QuantumToasted]

For my current project use case I don't think I would switch EnC on - the workflow and design of the project as well as the libraries it uses would not be affected by EnC - namely that one library has things generated once at runtime and would require me to restart the debugging session anyways. However I could certainly see use cases for other projects (and developers!) who previously had EnC off for the same reasons as I, to switch it back on.

[dougmeeker-dss]

The only reason I have turned off EnC is so that I can edit code while the dev server (IIS or console) is running. This keeps me from having to press Shift-F5, do some edits and press F5. I much prefer editing and pressing Ctrl-Shift-F5. It save the stopping step. Having it running also helps me evaluate what is going on as I am editing so it is beneficial to have the dev server running even if I am not using break points. Having a way to suppress the "these changes are not reflected...." warning would be great.

[tmat]

@dougmeeker-dss Does the new experience work for you with ENC turned on, other than the reported warning?

[dougmeeker-dss]

Yes that would work for me. I used VS2019 with ENC turned on for a wile. I liked that code editing was now allowed. I only turned it off to get rid of the warning and then stopped using 2019 when the purple lines showed up.

[pettys]

For those that want to make this less obnoxious-looking until it's fixed, it's Tools -> Options -> Fonts and Colors -> Rude Edits (which I find to be an ironic name for it now).

[dsparkplug]

The purple underline actually works quite well when EnC is enabled, as it indicates that the change is only established when stopped at a breakpoint. It is however useless and annoying when EnC is disabled, for whatever reason, and needs to be optionally suppressed.

[pettys]

@tmat Your comments seem to be encouraging people toward turning EnC back on again. So I turned EnC back on to see if the experience has improved since I got frustrated with it years ago. Here's the scenario I just hit:

1. Web project: I'm writing a unit test to reproduce a bug I'm seeing when running the web site.
2. I drop a breakpoint in the code so I can inspect the method input values that are causing the issue.
3. I exercise the website to hit the breakpoint.
4. I examine values of variables at the current breakpoint, and add code to the unit test based on this information. In order to write this unit test, I add a "using" to the top of the unit test file. (This is not an EnC-supported code change, evidently.)
5. Desired Result: I'd like the continue stepping through the debug session now. With EnC off I can do this very easily. I usually don't care that the changes I made won't be part of the running app.
6. Actual Result: Visual Studio won't let me continue: "Edits were made which cannot be compiled. Execution cannot continue until the compile errors are fixed." The only errors in my Error List are "Adding 'using directive' will prevent the debug session from continuing."

For me, I want to freely edit code even when attached to my process. The restrictions EnC imposes even in cases when you don't want the EnC benefits feel too cumbersome to me. In the case I hit, if there were an option, "Continue debugging this session without EnC," then maybe EnC would be worth switching on again.

So I realize this is side-bar information; you seemed interested in hearing why people aren't using EnC. I hope this bug gets fixed soon - even when squelching the annoying "Rude Edits" coloring, it still sometimes masks compile error red squiggles, so it's still annoying.

[tmat]

@pettys Thanks for the feedback. Suppose we allowed adding using directive, so that the change can actually be applied to the app without restarting the debugging session and rebuilding. Wouldn't that be what you actually want?

In the case I hit, if there were an option, "Continue debugging this session without EnC,"

This is an improvement we are considering.

[pettys]

@tmat Thanks for responding.

Suppose we allowed adding using directive...

Probably. Realize that the "adding using directive" is just the example I happened to hit, so adding that particular case into the list of allowed edits probably won't make much difference to me. Any situation where I'm blocked from editing code until I end the debugging session is disruptive. I think to myself, "Oh, block me from editing, will you? I'll open a separate text editor and edit the file any way I want." Miraculously (sarcasm) VS works fine 99.9% of the time even when you edit files it doesn't want you to. The infrequent "Visual Studio can't find the source at this point," is completely expected and reasonable.

Similarly, Visual Studio unfortunately prevents deleting and renaming all files during a debug session. It prevents deleting .ts files, even when VS's script debugger isn't being used. This is a related Visual Studio pet peeve of mine -- shuffling around .ts, .js, .css, etc. files during an ASP.NET debug session is a very reasonable and safe thing to do.

These are probably relatively small issues, but when my head is totally in the flow of writing sweet code, and then VS shows up like a brick wall out of nowhere to prevent the code from happening, it's tripping the joy. Like bonking into a glass door you didn't see. At this time, turning EnC off makes VS go with the flow a little better.

"Continue debugging this session without EnC,"

This is an improvement we are considering.

That would be cool.

[tmat]

@pettys Starting at 16.3 we don't ever block you from editing source files anymore. So you don't need to open a different editor anymore. Whether or not you can continue stepping after you make source changes is a different question. There the tradeoff is between being able to trust what the debugger shows you in watch windows, place breakpoints, etc. and ability to continue debugging. If we provide the option to continue debugging without applying the changes and you use it you accept the fact that the debugger features might stop working in the edited source file in rather unpredictable way since now the source code doesn't match the code that executes in the debuggee.

[pettys]

@tmat That clarification is helpful, that VS doesn't block file edits any more since 16.3. Thanks! (Deleting and renaming would still be nice.) Getting into debug sessions where the source code doesn't match the debug symbols is something I've understood and had no problem dealing with for years, for what it's worth.

[tmat]

Fixed.