Problem debugging VSIX with the "Analyzer and CodeFix (.Net Standard)" Template

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

[severity:It's more difficult to complete my work] When one creates a new Solution using the project template "Analyzer and CodeFix (.Net Standard)" and then debugs the solution, breakpoints in the analyzers and code fix providers are not hit as expected. Steps to reproduce:

• Create a new solution using the template "Analyzer and CodeFix (.Net Standard)", leave everything at default. A Solution with several projects based on the name "Analyzer1" will be created
• Put a breakpoint into line 42 of the generated file Analyzer1Analyzer.cs
• Start debugging choosing the "Analyzer1.vsix" entry in the lauch dropdown. A second instance of VS 2019 marked ROSLYN will start.
• Open any project containing a type declaration, e.g. the project "Analyzer1.Test" in the generated solution, and wait for code analysis to finish. The type declaration will be annotated by the example analyzer with “Analyzer1: Typename … contains lowercase letters”.
• The breakpoint in line 42 will not be hit at this time. Actually, this message should not appear without the breakpoint being hit.
• When pressing CTRL + . and hovering over the “Make uppercase” code fix, the breakpoint is hit.

Expected behaviour: every time the analysis is performed, execution should stop at the breakpoint, or at any other breakpoint in the Analyzer1Analyzer class in the execution path of the analysis.

---

Original Comments

Feedback Bot on 2/10/2021, 00:50 AM:

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.

Feedback Bot on 3/8/2021, 10:22 AM:

Thank you for sharing your feedback! Our teams prioritize action on product issues with broad customer impact. See details at: https://docs.microsoft.com/en-us/visualstudio/ide/report-a-problem?view=vs-2019#faq. In case you need answers to common questions or need assisted support, be sure to use https://visualstudio.microsoft.com/vs/support/. We’ll keep you posted on any updates to this feedback.

Zoey Wang [MSFT] on 3/17/2021, 07:35 PM:

Thank you for your feedback! Unfortunately we are not able to reproduce your problem, In order for us to investigate this further, could you please provide the reproduce steps and a sample solution that has this problem so that we can conduct further research? We look forward to hearing from you!

Hans-Christian Knöppler on 3/22/2021, 01:15 AM:

Hi Zoey,

sorry, I don’t understand this request. If the status is “Triaged”, doesn’t that mean that the problem has been reproduced?

The steps I have provided are very clear. Also, the sample solution is just the standard VS project template I mentioned in the title. So, what exactly is the additional information you need?

Regards,

Hans-Christian

Kazys Račkauskas on 3/22/2021, 01:19 AM:

I experience the same problem, with default project template without any additional changes as mentioned in issue description

Zoey Wang [MSFT] on 3/24/2021, 08:39 PM:

Thank you for sharing your feedback! And I’m so sorry that I have a little misunderstanding about this feedback, I can reproduce this problem now and changed the status.

Feedback Bot on 5/11/2021, 01:04 AM:

I detected that this issue hasn’t received a lot of activity, votes, or comments in the past 90 days. Based on this, the issues severity and affected area, it’s my experience that this issue is unlikely to get fixed. To improve the situation, consider following best practices for quality problem reports, and giving us more details on how this issue is impacting you.

Hans-Christian Knöppler on 5/11/2021, 04:22 AM:

Dear Feedback Bot, it is quite alright that this issue is probably difficult to fix and might not affect many people, but I don’t see how this relates to the quality of my problem report… 😉

info on 5/14/2021, 06:29 AM:

(private comment, text removed)

Jaroslav Danicek on 7/15/2021, 11:24 AM:

This is really unfortunate, i would like to continue to develop roslyn analyzers but with this problem its not possible. It became basically a blackbox. Its not possible to debug them via unit tests either. This was one of things that was making visual studio more enhanced than rider.

Feedback Bot on 7/15/2021, 11:46 AM:

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)

[mconnew]

I hit this issue and have worked out what the problem is. VisualStudio is attaching to the wrong process. It's attaching to the devenv.exe process that's the test instance of Visual Studio, but the Roslyn Analyzer being developed is being run in a child process called ServiceHub.RoslynCodeAnalysisService.exe. I used the sysinternals tool Process Explorer to find which process had my analyzer dll loaded as there are multiple intstances of that process in memory, one for each instance of VS running I believe.

[mconnew]

I've worked out a workaround so I can debug relatively seamlessly.

1. Install the "Microsoft Child Process Debugging Power Tool" Visual Studio extension available here.
2. In your .visx project, on the Debug tab you need to enable native debugging.
3. In the VS extension configuration available via Debug -> Other Debug Targets -> Child Process Debugging Settings, you need to set things up like this:

Then when you start the .visx project, it will launch the VS test instance, which then launches Microsoft.ServiceHub.Controller.exe, but only with Native debugging (so it can detect another child process launch with minimal debugging hooks), which then launches the roslyn code analysis process with only Managed debugging. The first time it will take quite a while to launch as it needs to download all the native symbols first, but once they are downloaded, you should be good to go.

[silkfire]

Great find regarding the workaround, Matt! This should be helpful to the VS developers for them to fix the original issue as well, I believe :)

[FrankSzendzielarz]

I also managed to get this working by : a) Downgrading the Analyzer's references to Microsoft.CodeAnalysis.Analyzers and Microsoft.CodeAnalysis.CSharp to 2.9.8 and 3.3.1 respectively b) In the experimental instance Options -> Text Editor -> C# -> Advanced -> Disable "Use 64 bit process for code analysis"

[bkoelman]

I'm stuck by this too. Reverting to VS 2019 for analyzer development until this is fixed. The option "Use 64 bit process for code analysis" no longer exists in VS 2022 v17.0.4.

[danstur]

So has the team decided to no longer support debugging of Roslyn extensions in Visual Studio?

It'd be nice if someone could remove a known broken part of a template that's officially shipped to stop people wasting their time trying to get this to work.

[bkoelman]

This solved the problem for me:

When using Visual Studio 2022 or higher, breakpoints don't get hit unless you change the following setting in the experimental instance: Tools > Options > Text Editor > C# > Advanced > Uncheck 'Run code analysis in separate process'

[danstur]

@bkoelman I also had to update my vsixmanifest to so that all Version dependencies were for 17.0 instead of the default 15.0 and then add <ProductArchitecture>amd64</ProductArchitecture> to the InstallationTarget.

[rpbeukes]

Thanx for all the input, y'all!

I too had this issue but solved it a different way.

Found very good help from Troubleshoot Breakpoints in the Visual Studio Debugger

In Visual Studio 2022, run your code in debug mode then...

Go to the Modules window (Debug > Windows > Modules) and check whether your module is loaded.

• In the search bar, I entered my code file name, and I saw that Symbol Status indicated: file not found.
• Right-Clicked on my file and choose Open File Location.
• Dig around in there, and discover an interesting folder I wanted to delete eg: C:\Users\{YourUser}\AppData\Local\Microsoft\VisualStudio\17.0_ad6c95ffRoslyn.
• Stop the debugger and close VS.
• Deleted the folder
• Re-open VS
• I monitored the folder C:\Users\{YourUser}\AppData\Local\Microsoft\VisualStudio\ and a new extension folder appeared.
• Now the debugger worked again.

Hope this helps someone :)

[Vannevelj]

This solved the problem for me:

When using Visual Studio 2022 or higher, breakpoints don't get hit unless you change the following setting in the experimental instance: Tools > Options > Text Editor > C# > Advanced > Uncheck 'Run code analysis in separate process'

I've done a bunch of things but this seems to have been the solution for me as well. I've verified that if I turn it back on my breakpoints don't get hit. Turning it off and restarting immediately solves the problem.

[peteraritchie]

from: https://github.com/dotnet/roslyn-sdk/issues/515#issuecomment-764744872 from @sharwell

Analyzers do not run in a single known process that allows debugging. The recommended approach is as follows:

For stepping through analyzers in the debugger, write unit tests using the analyzer test library (e.g. all the tests in dotnet/roslyn-analyzers). Visual Studio's Test Explorer allows individual tests to be run in a debugger. For high-level validation that does not involve a debugger, the VSIX project may be used to launch Visual Studio with the analyzer enabled. This is meant as a general way to see how the analyzer behaves in a full project, but does not directly support debugging.

I'd recommend this issue be closed.

[d1820]

This has also affected my extension even being able to run (multiple bug reports). There is definitely a bug in these packages to allow them to work properly out of process. What i noticed happening is none of the analyzers load even though the extension is loaded. Even redoing my extension to the latest templates from VS2022 17.6.5 with latest Niuget packages still had no effect until i unchecked run in separate process.