none
VS2019 16.0.4 May 2019 - still seeing "edits were made to the code which cannot be applied" RRS feed

  • Question

  • Hi,

    I have a .NetCore 2.2 console app in C# with Razor pages. I do a full clean followed by a full Rebuil All. I then set a breakpoint in a razor page, and Run the Debugger. I hit my breakpoint and I get the error "Edits were made to the code which cannot be applied".

    I hit stop, then <f5> again to restart the debugger and it works the second time.

    I realize I can turn off Edit and Continue to stop this from happening, but that defeats the purpose of being able to edit my razor page and continue.

    Is this a known bug in VS2019?


    Michael

    Thursday, May 23, 2019 2:07 PM

All replies

  • Hi Michael,

    Welcome to MSDN forum.

    According to your description, I could not reproduce this issue in my side, and the visual studio 2019 is 16.1.0 in my side. Please update the VS2019 to the latest version then re-debug your project.

    If there is any update information, please feel free to contact us.

    Best Regards,

    Dylan


    MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com

    Friday, May 24, 2019 8:52 AM
  • Nope, still happens even with 16.1.0. I upgraded, rebooted, clean all, rebuild all, and it still throws the error.



    Michael

    Tuesday, May 28, 2019 12:04 AM
  • Hi Michael,

    Thank you for reply.

    I share an export a vssettings file for debugging setting via one drive. After back up your settings, please download and import your visual studio, and then try to re-debug your project.

    Note: Tools/Import and Export settings.../Import selected environment settings

    Any feedback will be expected.

    Best Regards,

    Dylan


    MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com


    Wednesday, May 29, 2019 5:21 AM
  • Hi friend,

    Any update for this issue? Have you tried Dylan's suggestion? Please let us know if it's helpful or not.

    Also, maybe you can get some help from this thread

    Check this:  1. If any file is created under wwwroot or its subdirectories while the debugging session is active, then VS will prompt for Stop or Edit after hitting a breakpoint and trying to continue. In my case it was Elmah that was creating files under wwwroot/logs. I ended up changing to log path to "~/../App_Data/ElmahLogs".

    Best Regards

    Lance


    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Thursday, June 6, 2019 6:00 AM
  • Yes, this vsssetting file seems to have corrected the issue. I have not had another occurrence since importing this special file.

    I have not had the opportunity to see the diff on the files yet to determine the setting that corrected the problem.

     


    Michael

    Thursday, June 6, 2019 1:19 PM
  • Opps, Looks like I spoke too soon.

    I applied the latest 16.1.2 update and now the bug is back...ARGGGGGGG!


    Michael

    Tuesday, June 11, 2019 8:36 PM
  • Hi Michael,

    Thank you for feedback.

    Did you try to re-import the vssettings file which I shared into visual studio? It may automatically be overwritten by the previous settings which is after the update.

    So firstly, you could exported current settings to back up, then import settings file which I shared.

    If this issue persists, I would appreciate that you could share a sample to help us analysis it better.

    Look forward to your reply.

    Best Regards,

    Dylan


    MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com

    Wednesday, June 12, 2019 8:33 AM
  • No, I didn't try re-applying your hot-fix after installing the latest round of, well, hot-fixes from MS during the weekly hot-fix rollup release.

    Oh I don't know, maybe the MS team could fix the bug since we know the magic VS settings which are causing the issue?


    Michael

    Wednesday, June 12, 2019 1:08 PM
  • Today I installed 10.1.3, then restarted the OS, then re-applied the hot fix then did a full clean and full rebuild all


    Michael

    Wednesday, June 12, 2019 9:33 PM
  • Hi Michael,

    Thank you for feedback.

    Please open Tools/Options/Debugging/ General , then check if the options with red line are enabled 

    And check if these types are enabled in Just-In-Time

    Any feedback will be expected.

    Best Regards,

    Dylan


    MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com

    Thursday, June 13, 2019 9:35 AM
  • ok, great, thanks for those details.

    Everything works until I turn off "Step Over Properties and Operators (Managed Only)" which I turn off because I have custom get {} set {} properties for some of my objects and I need to step into that code.

    As soon as you turn that feature off...the error appears. Even if you batch-build-clean-all-batch-rebuild-all.

    So the bug is somehow related to that setting.


    Michael

    Thursday, June 13, 2019 10:52 PM
  • Hi Michael,

    I’m glad to hear that you got it working.

    As far as I know, the "clean" just deletes any intermediate and output files. It could not modify the related settings.

    BTW, if possible, could you mark your reply as answer, and it will help other community members with similar issues.

    Have a nice day.

    Best Regards,

    Dylan


    MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com

    Friday, June 14, 2019 7:14 AM
  • Hi,

     I believe you misread my response. No it is not working.

    If you enable Step Over Properties And Operators you will see the bug.



    Michael

    Sunday, June 16, 2019 8:22 AM
  • Hi Michael,

    Sorry for my misunderstanding.

    The "Step Over Properties and Operators (Managed Only)" is to prevent the debugger from stepping into properties and operators in managed code. And the managed code the code is directly executed by CLR,it is developed in framework, the code we edit is "un-managed code", it is out of framework. When the option closes, the IDE would recognize the debugging mode is mixed(native and managed), but debugger is not able to support "Edit and Continue". Please refer more here.

    So we suggest the you could turn on this option, and debugger could debug the properties of get and set normally. 

    Any feedback will be expected.

    Best Regards,

    Dylan


    MSDN Community Support Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com

    Tuesday, June 18, 2019 9:03 AM
  • Hi,

    Thanks for the info, but again, you missed my point. I have a fully managed .net core 2.2 console application with no mixed mode, purely 100% managed c#.

    I have built lazy-loading into many of my classes to ensure that complex objects are not created until the first 'get' call

    public class foo
    {
      private ComplexClass1 _cc;
      public  ComplexClass1 MyMember  
      { get { return _cc?? (_cc=new ComplexClass1()); }  }
    }

    so the ability to Step Into Getters/Setters is required. However, when I turn this feature on, everything else is broken due to the original error.



    Michael

    Tuesday, June 18, 2019 3:10 PM