none
Break Point Taking Affect in Chrome and Not in Visual Studio RRS feed

  • Question

  • I am new to learning Blazor WebAssembly with accompanying TypeScript and JavaScript files.  I have a test app up and running, but am experiencing what appears to be inconsistent debugger behavior.  In the current situation, I have set break points in an async JS function.  When I debug the app (using Chrome), it appears that Chrome's debugger is taking over, thereby preventing me from using VS to examine my code.  I know that I have done this recently and the break occurred in VS as I would have expected/hoped.  So I'm not sure what has changed the behavior.  I'm including a screenshot of the break within Chrome.  

    Thanks for any help you can provide.

    Steve

    Saturday, June 6, 2020 1:46 PM

Answers

  • Thanks, Dylan.  I had "Enable JavaScript debugging..." checked already.  

    <o:p>As with my other posted question, I may have stumbled onto the problem in this case.  While rereading this (https://docs.microsoft.com/en-us/aspnet/core/blazor/debug?view=aspnetcore-3.1), I noticed that my launchSettings.json file contained '"nativeDebugging": true,' in the IIS Express profile.  Now that I've removed it, debugging break points now seem to be back in Visual Studio.  Soemthing must have prompted me to add that setting at some point, but I am at a loss to recall when or why.</o:p>

    <o:p>Hopefully this one is solved too.</o:p>

    <o:p>Steve</o:p>

    • Marked as answer by Cincy Steve Tuesday, June 9, 2020 8:03 PM
    Tuesday, June 9, 2020 8:03 PM

All replies

  • Hi Cincy Steve,

    You can try to enable "disable cache(while DevTools is open)" in debugger options.

    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

    Monday, June 8, 2020 3:30 AM
  • Dylan -

    Thanks for your help.

    Your suggestion looks like it might be related to a different question I have posted (https://social.msdn.microsoft.com/Forums/en-US/626cf400-4044-42e0-859f-d51d6bb65be5/javascript-code-change-is-not-be-applied?forum=visualstudiogeneral) for which you have been making suggestions.  I am not sure how it applies to this question.

    Anyway, I have "Disabled cache (while DevTools is open)" as you suggested.  This neither solved my other problem (JavaScript changes not loading, which seems related to caching) nor this one (where Chrome's debugger is taking charge over Visual Studio's).  

    Perhaps I am missing something related to the "Disable cache" suggestion, but:

    1.  Seems like it might be too late to have an effect on my other problem since the js code changes are failing to load before the point where I open DevTools; and

    2. Checking this setting is not being persisted.  After I close the app, rerun it, and open DevTools, the option is no longer selected (perhaps I don't yet know how to make DevTools work fully).

    I am sorry that I haven't yet figured out how to effectively use your suggestions to solve my (now 2) problems.  Thanks in advance if you have any other thoughts on what I am missing.

    Steve

    Monday, June 8, 2020 6:52 PM
  • Not familiar with ASP.NET debugging, but think there exists an option in 'Tools -> Options -> Debugging -> General', which may prevent that Chrome is using its own dev tools:


    With kind regards


    Monday, June 8, 2020 10:37 PM
  • Thanks, Dylan.  I had "Enable JavaScript debugging..." checked already.  

    <o:p>As with my other posted question, I may have stumbled onto the problem in this case.  While rereading this (https://docs.microsoft.com/en-us/aspnet/core/blazor/debug?view=aspnetcore-3.1), I noticed that my launchSettings.json file contained '"nativeDebugging": true,' in the IIS Express profile.  Now that I've removed it, debugging break points now seem to be back in Visual Studio.  Soemthing must have prompted me to add that setting at some point, but I am at a loss to recall when or why.</o:p>

    <o:p>Hopefully this one is solved too.</o:p>

    <o:p>Steve</o:p>

    • Marked as answer by Cincy Steve Tuesday, June 9, 2020 8:03 PM
    Tuesday, June 9, 2020 8:03 PM