search

microsoft / sarif-sdk

.NET code and supporting files for working with the 'Static Analysis Results Interchange Format' (SARIF, see https://github.com/oasis-tcs/sarif-spec)
Other
191 stars 88 forks source link

chore: emit portable debug files #2740

Closed rwoll closed 8 months ago

rwoll commented 8 months ago

This change supports debugging from VSCode.

Prior to this change, if debugging using VSCode (including on Windows), a warning like the following would be emitted for each of the DLLs:

WARNING: Could not load symbols for 'Sarif.dll'. '…\Spmi\bld\bin\AnyCPU_Debug\Sarif.PatternMatcher.Cli\net6.0\Sarif.pdb' is a Windows PDB. These are not supported by the cross-platform .NET Core debugger.

and breakpoints set in VSCode would not be triggered.

To fix this, we switch to the portable DebugType.

For more information, see:

Notably:

Supported scenarios

Today, neither portable PDBs nor Windows PDBs are supported everywhere so you need to consider where your project will want to be used (or at least debugged) to decide which format to use. If you have a project that you want to be able to use and debug in both formats, you can use different build configurations and build the project twice to support both types of consumer.

Windows PDBs can only be written or read on Windows. All Windows tooling supports them, except for Visual Studio Code (as Visual Studio Code strives for consistent behavior across all platforms), and scenarios where Visual Studio is debugging to a remote Linux/OSX computer (as the PDBs must be read on the remote computer). Portable PDBs can be read on any operating system, but there are a number of places where they [are not supported yet]. Here are a few –

  • Older versions of the Visual Studio debugger (versions before VS 2015 Update 2).
  • Applications targeting .NET Framework 4.7.1 or earlier1: printing stack traces with mappings back to line numbers (such as in an ASP.NET error page). The name of methods is unaffected, only the source file names and line numbers are unsupported.
  • C# Code analysis (aka FxCop), note that this doesn't apply to Roslyn Analyzer.
  • Some symbol servers (ex: SymbolSource.org does not, nuget.org does)
  • Running post-compilation build step that consumes or modifies the PDB using older versions of tools such as CCI, CodeContracts.
  • Using .NET decompilers such as ILDASM or .NET Reflector and expecting to see source line mappings or local parameter names.
  • MS DIA-based tools such as WinDBG.

Over time we plan to shrink this list of non-supported scenarios so that portable PDB can become the default choice for most usage needs.

Given the above, this PR helps folks using VSCode (like me) without impacting devs using VS (assuming a version of VS from the past few years).

NB: ReleaseHistory.md explicitly does not have an update since this (1) only impacts the Debug (not Release) target, and (2) adds more debugging support but does not remove.

rwoll commented 8 months ago

Switching to draft while debugging some build/test errors internally.