PDB generated by command line msbuild is not allowing Visual Studio to Debug

[mtrutledge]

Describe the bug

When you run npm run build and the gulp task triggers msbuild the resulting PDB files generated do not allow an instance of Visual Studio to attach the debugger properly.

To Reproduce

Steps to reproduce the behavior:

1. Create a project
2. run npm run build
3. Deploy the project to a local DNN instance
4. copy the PDB files over to the DNN instance bin directory
5. Launch Visual Studio and open the project
6. Set a breakpoint and attach the debugger to the w3p.exe process running the DNN instance
7. Load the module and see the breakpoint will never be hit.

Expected behavior

The PDB generated from the command line should allow Visual Studio to attach the debugger and hit the breakpoint properly

[mtrutledge]

NOTE: If you build the csproj file from within Visual Studio the PDBs generated allow attaching to the debugger properly.

[mtrutledge]

Moving a comment from another issue to this issue.
@ahoefling said:
"I did a quick search and I think I found something that may be helpful in our research. It appears there is full .NET Framework debugger support in VS Code (I had no idea). The problem is you need to specify your PDB as portable. My guess is we aren't passing that in the msbuild arguments like you mentioned above.

Take a look at this thread which I found helpful in this topic

dotnet/vscode-csharp#813
"

[mtrutledge]

In the new csproj files DebugType is set to Portable by default since VS Code and the omni sharp plugin want to use those for debugging. If using full visual studio and Portable is not working the project settings can be changed to full.

[bdukes]

FYI, from https://github.com/dotnet/core/blob/master/Documentation/diagnostics/portable_pdb.md#supported-scenarios

Portable PDBs can be read on any operating system, but there are a number of places where they aren't 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 earlier¹: 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
• Symbol server (ex: SymbolsSource.org)
• 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.

1. When running on .NET Framework 4.7.2 with an app that targets earlier .NET Framework versions we anticipate having an opt-in configuration switch as an additional mechanism to enable support for older applications↩