Improve NuGet package debugging and symbols experience

[diverdan92]

Currently the NuGet package debugging and symbols experience is not streamlined.

Some areas that need improvement are:

1. Optimize the NuGet package and symbol authoring story to encourage ####production of symbols
2. Support for the new portable PDB format for .NET Core and .NET Standard applications
3. Better integration in Visual Studio tooling.

This issue will be used for discussion of the spec here.

[maartenba]

Would love to see this! Have had an offline discussion with some other folks, and came up with a dream workflow:

The main issue today is that when running “nuget.exe pack -Symbols” on a .NET Standard project, SourceLink is not enabled by default. Which makes a LOT of sense as not everyone is keen on sharing their sources. However: when people do want to have sources support, it’s usually too late and discovered during a debugging/profiling/dump analysis situation where symbols and sources would have been handy…

Going out on a limb, perhaps the ideal workflow would be something like this (trying to shape a flow and feature):

Package creation/publishing phase

• User, when packaging using nuget.exe pack -Symbols for Portable PDB
  • If the Portable PDB does not contain embedded sources + sourcelink
    • Check whether source_link.json is available. If not:
      • Generate one based on the current folder and make sure the Portable PDB contains it (may need a recompile… so maybe generating one should be a default of csc.exe instead of a NuGet feature)
        • The mapping would be “”: “%sourceservertemplate%/” (where documentname is actually filled out, and %sourceservertemplate% is a placeholder that is embedded into the file.
• User can then publish NuPkg and symbols NuPkg to wherever they want. If that “wherever” supports symbols, then yay!

Symbols consumption phase (user wants to fetch symbols and sources)

• If the Portable PDB is embedded in the assembly and has embedded sources etc, use the VS SourceLink feature to show sources
• If the Portable PDB must be downloaded, then download it from the configured symbol server using the traditional semantics of PDB ID and PDB name
  • After download, if sources are embedded, use the embedded sources
  • If sources are not embedded but the source_link.json is, and has a URL for document mappings, use the URL
  • If sources are not embedded but the source_link.json is, and has a URL that contains %sourceservertemplate%, interesting things happen!
    • 1. The debugger/VS/… would reach out to the symbol servers configured in VS and fetch, for example, http://symbolserver.local/services.json. This services.json would contain the actual value for %sourceservertemplate%. The value would be cached for the entire debugging session.
    • 2. The debugger/VS/… uses the %sourceservertemplate% placeholder in the URL that was in source_link.json, then fetches the sources from there.

That seems, for Portable PDB, to give the entire spectrum of embedded + sourcelink, to sourcelink with url mappings, to no sourcelink at all but still have debuggability.

[diverdan92]

@maartenba -

a. The debugger/VS/… would reach out to the symbol servers configured in VS and fetch, for example, http://symbolserver.local/services.json. This services.json would contain the actual value for %sourceservertemplate%. The value would be cached for the entire debugging session.
b. The debugger/VS/… uses the %sourceservertemplate% placeholder in the URL that was in source_link.json, then fetches the sources from there.

The way you envision this working, where would the source be uploaded to support these scenarios? It seems like the package author has not uploaded the source in this case?

[maartenba]

That comes from the creation phase:

• User, when packaging using nuget.exe pack -Symbols for Portable PDB
  • If the Portable PDB does not contain embedded sources + sourcelink
    • Check whether source_link.json is available. If not:
      • Generate one based on the current folder and make sure the Portable PDB contains it (may need a recompile… so maybe generating one should be a default of csc.exe instead of a NuGet feature)
      • The mapping would be “”: “%sourceservertemplate%/” (where documentname is actually filled out, and %sourceservertemplate% is a placeholder that is embedded into the file.

This is essentially the current NuGet behavior, where the generated package contains sources and a sourcelink file that holds a placeholder URL. That way, a server can serve up symbols based on the embedded sources.

Imagine the following scenario that you can do today:

• User runs nuget pack -Symbols and generates a .nupkg and .symbols.nupkg.
• User uploads both to server, and consumes only .nupkg in their project
• All of a sudden, debugging is required! They configure a symbol server that serves up the Portable PDB that was in .symbols.nupkg, and expect things to work. Except: they do not!
  • The Portable PDB contains some info, but not sources. It also does not contain a link to the sources. In other words: the user will not be able to do debugging.
  • If instead, NuGet had added the template URL to sourcelink (and VS could work with it), VS could query sources using that template URL, fetching the source files that were in the .symbols.nupkg

Another option is embedding the sources in the Portable PDB, which would be awesome, except for one thing: there is no user control possible. E.g. if I am a tools vendor and I want only my team to have debugging possibilities and not my clients, how do I prevent one group from using the symbols embedded in the Portabe PDB? For this scenario, having to reach out to the server will make it possible to limit access to PDB and source files.

[tmat]

@maartenba We are working on making it super easy to enable source link in builds for both public and private repos, as well as embed sources to PDBs that not tracked by a source control server (e.g. sources generated during the build). Our goal is to reduce the number of packages that were not built with source link or embedded sources. That said, we understand that there will be cases where it will be necessary to add sources after the fact. The scenario is valid and we have some ideas how to address it in future. I don't think NuGet is the right tool to implement this support though (by creating source link files or recompiling PDBs).

[anangaur]

When publishing packages, both the .symbols.nupkg and the .nupkg will be published to NuGet.org. We will make the nuget and dotnet push CLI automatically push both .nupkgs and .symbols.nupkgs (if they exist). We will add a parameter to the dotnet and nuget CLIs to opt out of automatic pushing of .symbols packages.

I would say we should opt in to publish the symbols and by default only the .nupkg is pushed not the .symbols.nupkg.

We are already taking the change to not auto-push package. (See #6113). Lets not randomize :)

[diverdan92]

Draft of the spec is now available here: https://github.com/NuGet/Home/wiki/NuGet-Package-Debugging-&-Symbols-Improvements

Please let us know any feedback you have in this thread!

[dotMorten]

Questions from reading the draft spec:

1. Will be able to host our own symbol server / will the nuget server nupkg be updated to support this?
2. Will the below requirements also apply to private symbol servers?

Requiring 4.7.1 is way too soon for us, and also we'd like to continue using our existing native PDBs as well.

3. Will source linking support multiple repos (at the very least one per .dll), and will you support on-premise git servers?

4. How will source linking work wrt to versioning? Do we need to specify a specific commit or tag for each repo we're source-linking to?

[ctaggart]

Great write-up @diverdan92. Thanks for sharing the plan. I'm trying to better understand the advantages of using a symbol server instead of just including the .pdb files in a normal .nupkg.

If a .pdb is included in a normal .nupkg, NuGet and NuGet.org will not do any special validation or indexing of the .pdbs. Debugging of the .nupkg will work in a limited way as the symbols will be cached next to the .dll, but it will not be indexed and downloaded from a symbol server. The only way to ensure indexing on the symbol server is to include the .snupkg. If the symbols are not indexed, certain scenarios will not work, such as crash dump debugging and attaching to an application.

So you can't do crash dump debugging or attach to an application with just .pdb files on the filesystem distributed via the normal .nupkg???

[jnm2]

I had a similar thought- all that complication to save a bit of disk space? Hey, if you're willing to do that, and keep it simple for both authors and consumers, more power to you!
The news about the UI is particularly encouraging. Educating people and lowering the barrier to stepping into library source will bring us closer to a world in which every library comes with symbols and all consumers make use of them. I expect the quality of bug reports to go up when it's no longer a black box and a curious mind can figure out a minimal repro so much more easily.

[dotMorten]

I had a similar thought- all that complication to save a bit of disk space?

My PDBs are over 500mb each, and there's 3 CPU architectures, meaning over 1.5gb of PDBs uncompressed! (about 400mb compressed in the nupkg)

Currently there's a 250mb limit on nuget.org.

[diverdan92]

@dotMorten

Excellent questions!

1. Yes, you should be able to host your own symbol server. You can setup your NuGet server to do the processing of .snupkgs manually, or you can just spin it up as a regular server to distribute .pdbs (e.g. upload directly to your symbol server, rather than to your own NuGet server).
2. The policy we are imposing is specific to the NuGet.org server. You are free to decide which policies you would like to apply to your own private symbol servers.
   3 + 4. @tmat is the expert here. Can you chime in?

@ctaggart - Great feedback. The issue is trying to debug a crash dump for a .dll you don't necessarily have restored/installed. If it's hosted on a Symbol server and you have it correctly configured, the tooling will automatic fetch the symbols to get meaningful debugging information. If you have everything installed and can locate the Symbols for the debugger, you can still get this to work including the Symbols as a part of the package, it's just not as ideal as it could be.

One of the open issues we need to close on is "How do we support preemptively caching symbols for offline scenarios". We do recognize a need for preemptive caching and are looking at the best ways to solve this. Any suggestions?

[ctaggart]

The issue is trying to debug a crash dump for a .dll you don't necessarily have restored/installed. If it's hosted on a Symbol server and you have it correctly configured, the tooling will automatic fetch the symbols to get meaningful debugging information. If you have everything installed and can locate the Symbols for the debugger, you can still get this to work including the Symbols as a part of the package, it's just not as ideal as it could be.

@diverdan92, so if you include the .pdb files in the regular .nupkg, are there debugging scenarios that do not work? Wouldn't eliminating the need for Symbol Servers for a large portion of debugging scenarios simplify things for those scenarios? Why not make adding .pdb files to the regular .nupkg the default?

[diverdan92]

@ctaggart we don't want to bloat the entire NuGet ecosystem unnecessarily. It impacts nearly everything - from Visual Studio install time, project creation time (for most projects), restore times, and more. We also have evidence that a majority of users won't debug into third party components, so promoting a model where the .pdbs are included in the .nupkg by default, we impact the performance for everyone to support a scenario for more advanced users.

[ctaggart]

@diverdan92 As a compromise, can you support a scenario to restore the symbols upfront at the same time that we restore the packages? A RestoreSymbols target was suggested: msbuild /t:RestoreSymbols MySolution.sln. A property could work too.

[clairernovotny]

@ctaggart I was proposing a setting in the nuget.config file for this.

I also suggest having the symbol sever endpoint being part of the v3 protocol spec, being part of the feed info itself. Then each NuGet client can discover the symbol server endpoint info. You could enable the per-feed symbols with an on/off setting on the nuget.config feed item element easily then.

So you may want symbols from your myget feeds, but not nuget.org. And you'd have a setting in the nuget.config file to pull them on restore as well that's repo-wide. That way you can have a consistent team experience.

[diverdan92]

@ctaggart that's where the option issue came from 😊. We will do something for this scenario to support the ability to download symbols upfront. The exact mechanism is TBD.

[ctaggart]

I see this is labelled Priority:1. Would this be in the VS 2017 15.7 time-frame?

[diverdan92]

Still to be determined. There are several moving pieces (compiler work to embed hashes of .pdbs in .dlls, client changes, spinning up the service, etc...). I would expect it after 15.7, but we may be able to start lighting up certain scenarios between 15.7 and whatever is next. Can't make any promises just yet.

[tmat]

Will source linking support multiple repos (at the very least one per .dll), and will you support on-premise git servers?

Yes. The implementation we are working on will support git submodules if that's what you mean by multiple repos. You can even have one dll built from multiple submodules. It will also support sources included from NuGet source packages.

How will source linking work wrt to versioning? Do we need to specify a specific commit or tag for each repo we're source-linking to?

The build task will automatically determine the commit sha from the repository using Git API (or changeset number for TFVC repositories). No need to specify anything.

I have done some prototyping of integrating source control features to build.
You can find a short doc here: https://github.com/tmat/repository-info/blob/master/docs/Readme.md
I'm now working on turning the prototype to real features and packages.

[rrelyea]

@diverdan92 - nuget client has finished the work for 15.9 related to this.

trying to clean up this milestone. can we close this issue, or move to future milestone, or other?

[diverdan92]

@rrelyea - we should wait until the e2e scenario ships to close the issue.

[drauch]

I'm new to this proposal, just read on it on the blog. The thing I don't get: what's wrong with adding the PDBs to the original NuGet package? We've done that for years and haven't got any problems with it. Is this discouraged now?

[dotMorten]

You're bloating the package for no reason. Also forcing a larger deployment on others who might not care about 3rd party symbols but are only interested in symbols for their own code.

[JamesNK]

How do snupkg files relate to package signing? If the main package is signed then should both be signed?

Also should this guidance be changed - https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/nuget#symbol-packages

Is there any reason to still have PDB files in the main package?

[clairernovotny]

IMO, PDB's should be in the main package, always. It's much faster to have the pdb's around instead of downloading on-demand. Also, some things like .NET Native need the symbols to be on disk in advance in order to munge the PDB's to match the native output. Symbol server does not work for that scenario.

I believe snupkg should only be used for full pdb's, which are bigger, but that's the one type of symbol they don't support. PPDB's are small. Better yet, use embedded as the symbol type and it'll be compressed and put directly in the DLL. No extra symbols to keep track of! :)

[JamesNK]

Interesting. I'm going to create a PR in the library guidance. I'll advertise it and see what direction the discussion and consensus goes.

[clairernovotny]

@JamesNK Can you please post the issue link here when you do?

[JamesNK]

Update symbol packages guidance

[rrelyea]

Shipped. Closing

[chilakamarthi]

Hi All,
After Nov 2018 update, I am trying to Debug nuget package. Here is what I am doing

1. Created a sample library (with Portable PDB) and published it to nuget server (Both nuget package and symbols).
2. Created new sample app and installed my nuget package and setup all setting in Tools > Options.

When I try to debug it is asking me for cs file.

My understanding of nuget debugging:
My understanding is as I set symbols server and local path for Cache symbols, if symbols are not found, it is supposed to download automatically and take me to method which I am trying to debug from my test application. If it is asking me path for cs file, not sure if I missed any setting.

Any help?

[tmat]

If it's asking for a source file that means the debugger was able to fetch the PDB from the symbol server.

You should be able to confirm that by opening the Modules window (Debug > Windows > Modules) and find the line that corresponds to the library.

The PDB does not contain sources by default. There are a few options how to make sources available. In general, we recommend using SourceLink package to link the PDB to the repo.

[chilakamarthi]

Source link is not an option for us. We need to include source files or embed source files into PDB. With new framework first option is not possible. So, embedding source files into PDB is only option for us. I tried below code change:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
   <EmbedAllSources>true</EmbedAllSources> 
   <DebugSymbols>true</DebugSymbols>
   <DebugType>portable</DebugType>
   ....
 </PropertyGroup>

With this change, I could publish snupkg to nuget, at the time of debug, pdb downloaded to my local symbols folder, but I hit with .cs file not found error

I am facing the same issue as this

Any help to overcome this issue?

[jnm2]

@chilakamarthi I'd put those properties in an unconditional property group so that e.g. a release build stays consistent with the debug build settings you've shown above.

Which version of Roslyn is your build server using? The <EmbedAllSources>true</EmbedAllSources> property is ignored unless building with Roslyn version 2.10.0 (shipped in VS2017 Update 6) which first introduced it. Prior to that, you need <PackageReference Include="SourceLink.Embed.AllSourceFiles" Version="2.8.3" PrivateAssets="all" />.

Embedded source can only be consumed by users with VS2017 Update 5 or newer.

[chilakamarthi]

Right now I am testing it on my dev machine which got Ver 15.9.5

[chilakamarthi]

I included below two in .csproj, but still don't see cs files in PDB

<PackageReference Include="Microsoft.CodeAnalysis.CSharp">
  <Version>2.10.0</Version>
</PackageReference>
<PackageReference Include="SourceLink.Embed.AllSourceFiles">
  <Version>2.8.3</Version>
  <IncludeAssets>runtime; build; native; contentfiles; analyzers</IncludeAssets>
  <PrivateAssets>all</PrivateAssets>
</PackageReference>

I read here

Source Linking with NuGet Packages
There are several options to provide source code for step debugging with symbols:

• SourceLink to embed a reference in the PDB to a remote source to get the code. This is the recommended way and will be built into the tooling by default.
• PDB embedded sources, which provides the source code directly in the PDB
• Fully embedded PDBs, providing all debugging information and source code in the .dll
• Including the source files in the .nupkg directly. This method is no longer recommended and will not be supported in the tools.

Second point I am looking for and I am not able to create snupkg which includes source code...

[jnm2]

@chilakamarthi I'd first load the DLL up in dotPeek or similar to find out if the PDB is being correctly created. You should look for > Metadata > Portable PDB Metadata > CustomDebugInformation entries with a Kind of EmbeddedSource.

If the PDB appears to not have any EmbeddedSource entries, the problem is with the build setup and I'd use http://msbuildlog.com and search the build log for csc to find out exactly what CLI arguments are being passed to csc.exe

[chilakamarthi]

I tried what you suggested and it looks normal. Here is the screenshot:

And dotpeek shows below log:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn\csc.exe /noconfig /nowarn:1701,1702 /nostdlib+ /errorreport:prompt /warn:4 /define:DEBUG;TRACE /highentropyva+ /reference:C:\Users\insuh1\.nuget\packages\microsoft.codeanalysis.csharp\2.10.0\lib\netstandard1.3\Microsoft.CodeAnalysis.CSharp.dll /reference:C:\Users\insuh1\.nuget\packages\microsoft.codeanalysis.common\2.10.0\lib\netstandard1.3\Microsoft.CodeAnalysis.dll /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Microsoft.CSharp.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\mscorlib.dll" /reference:"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\netfx.force.conflicts.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.AppContext.dll" /reference:C:\Users\insuh1\.nuget\packages\system.collections.immutable\1.5.0\lib\netstandard2.0\System.Collections.Immutable.dll /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\System.ComponentModel.Composition.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Console.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\System.Core.dll" /reference:"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\System.Data.Common.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\System.Data.DataSetExtensions.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\System.Data.dll" /reference:"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\System.Diagnostics.StackTrace.dll" /reference:"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\System.Diagnostics.Tracing.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\System.dll" /reference:"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\System.Globalization.Extensions.dll" /reference:"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\System.IO.Compression.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.IO.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.IO.FileSystem.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.IO.FileSystem.Primitives.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Linq.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Linq.Expressions.dll" /reference:"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\System.Net.Http.dll" /reference:"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\System.Net.Sockets.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\System.Numerics.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Reflection.dll" /reference:C:\Users\insuh1\.nuget\packages\system.reflection.metadata\1.6.0\lib\netstandard2.0\System.Reflection.Metadata.dll /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Runtime.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Runtime.Extensions.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Runtime.InteropServices.dll" /reference:"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\System.Runtime.Serialization.Primitives.dll" /reference:"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\System.Security.Cryptography.Algorithms.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Security.Cryptography.Encoding.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Security.Cryptography.Primitives.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Security.Cryptography.X509Certificates.dll" /reference:"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\System.Security.SecureString.dll" /reference:"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\System.Threading.Overlapped.dll" /reference:C:\Users\insuh1\.nuget\packages\system.threading.tasks.extensions\4.3.0\lib\portable-net45+win8+wp8+wpa81\System.Threading.Tasks.Extensions.dll /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.ValueTuple.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\System.Xml.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\System.Xml.Linq.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Xml.ReaderWriter.dll" /reference:"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\Microsoft\Microsoft.NET.Build.Extensions\net471\lib\System.Xml.XPath.XDocument.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\Microsoft.Win32.Primitives.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\netstandard.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Collections.Concurrent.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Collections.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Collections.NonGeneric.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Collections.Specialized.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.ComponentModel.Annotations.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.ComponentModel.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.ComponentModel.EventBasedAsync.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.ComponentModel.Primitives.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.ComponentModel.TypeConverter.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Diagnostics.Contracts.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Diagnostics.Debug.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Diagnostics.FileVersionInfo.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Diagnostics.Process.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Diagnostics.TextWriterTraceListener.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Diagnostics.Tools.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Diagnostics.TraceSource.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Drawing.Primitives.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Dynamic.Runtime.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Globalization.Calendars.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Globalization.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.IO.Compression.ZipFile.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.IO.FileSystem.DriveInfo.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.IO.FileSystem.Watcher.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.IO.IsolatedStorage.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.IO.MemoryMappedFiles.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.IO.Pipes.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.IO.UnmanagedMemoryStream.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Linq.Parallel.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Linq.Queryable.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Net.Http.Rtc.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Net.NameResolution.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Net.NetworkInformation.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Net.Ping.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Net.Primitives.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Net.Requests.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Net.Security.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Net.WebHeaderCollection.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Net.WebSockets.Client.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Net.WebSockets.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.ObjectModel.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Reflection.Emit.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Reflection.Emit.ILGeneration.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Reflection.Emit.Lightweight.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Reflection.Extensions.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Reflection.Primitives.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Resources.Reader.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Resources.ResourceManager.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Resources.Writer.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Runtime.CompilerServices.VisualC.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Runtime.Handles.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Runtime.InteropServices.RuntimeInformation.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Runtime.InteropServices.WindowsRuntime.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Runtime.Numerics.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Runtime.Serialization.Formatters.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Runtime.Serialization.Json.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Runtime.Serialization.Xml.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Security.Claims.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Security.Cryptography.Csp.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Security.Principal.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.ServiceModel.Duplex.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.ServiceModel.Http.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.ServiceModel.NetTcp.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.ServiceModel.Primitives.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.ServiceModel.Security.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Text.Encoding.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Text.Encoding.Extensions.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Text.RegularExpressions.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Threading.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Threading.Tasks.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Threading.Tasks.Parallel.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Threading.Thread.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Threading.ThreadPool.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Threading.Timer.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Xml.XDocument.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Xml.XmlDocument.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Xml.XmlSerializer.dll" /reference:"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7.1\Facades\System.Xml.XPath.dll" /debug+ /debug:portable /filealign:512 /optimize- /out:obj\Debug\LearnNuGetDebugging.dll /ruleset:"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Team Tools\Static Analysis Tools\\Rule Sets\MinimumRecommendedRules.ruleset" /subsystemversion:6.00 /target:library /utf8output /deterministic+ /embed /embed:Math.cs /embed:Properties\AssemblyInfo.cs /analyzer:C:\Users\insuh1\.nuget\packages\microsoft.codeanalysis.analyzers\2.6.1\analyzers\dotnet\cs\Microsoft.CodeAnalysis.Analyzers.dll /analyzer:C:\Users\insuh1\.nuget\packages\microsoft.codeanalysis.analyzers\2.6.1\analyzers\dotnet\cs\Microsoft.CodeAnalysis.CSharp.Analyzers.dll Math.cs Properties\AssemblyInfo.cs "C:\Users\insuh1\AppData\Local\Temp\.NETFramework,Version=v4.7.1.AssemblyAttributes.cs"

[jnm2]

Yes, your screenshot and /embed in the csc arguments indicates that you're producing the PDB correctly. I'm out of ideas. Perhaps there's a setting here that causes VS to start working?

[chilakamarthi]

@jnm2 Thats it. now I could debug. Enable just my code was not checked in my VS2017. When I enabled that option, debug is working.

Thank you @jnm2

[tmat]

@chilakamarthi BTW, the package reference SourceLink.Embed.AllSourceFiles should not be needed in VS 15.9. The C# compiler provides the functionality out of the box. Just set property EmbedAllSources to true in your project.

[jnm2]

@chilakamarthi If 'Enable just my code' is checked, it means you don't want to debug into any code outside the current solution. Typically you want to only turn it off briefly.

I've found this to be very handy: https://marketplace.visualstudio.com/items?itemName=SamHarwell.JustMyCodeToggle You get a toolbar item and can set a keyboard shortcut.

[kerryjiang]

Does it work in Visual Studio Code?

[chilakamarthi]

It works finally.. On Oct 25, 2019 1:31 PM, Kerry Jiang <notifications@github.com> wrote: Does it work in Visual Studio Code? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#6104?email_source=notifications&email_token=AGVIXYRMY2FQ3KM5LSOXBB3QQKRW3A5CNFSM4EA3DIV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECHRKBQ#issuecomment-546247942>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AGVIXYVY2ACJQYPPTLTP6MTQQKRW3ANCNFSM4EA3DIVQ>.

[kerryjiang]

Is there any document about how to debug into snupkg with VisualStudioCode?

I cannot debug into it.

[chilakamarthi]

Pre requisites:
Visual Studio 2017 Version: 15.9.0 or later
Nuget Version: 4.9.3 or later

1. Edit project file in notepad and either update or add below tags in "Debug|AnyCPU" and "Debug|[Specific Platform]"
   <DebugSymbols>true</DebugSymbols> <EmbedAllSources>true</EmbedAllSources> <DebugType>portable</DebugType>
2. Compile the code
3. Create nuspec file with all required files like dlls and pdbs (Also for UWP include: include .pri, .winmd)
4. Ensure you set library folders properly. For UWP apps target should be like "lib\uap10.0...."
5. Add all dependencies
6. Command to create new nupkg and snupkg(new symbols format):
   nuget pack RobotStudio.Services.RobApi.Uwp.nuspec -Symbols -SymbolPackageFormat snupkg
7. Debug settings in Options:
   a. Symbols: Set network path and Symbols cache directory
   b. General: Enable Just My Code is checked
   c. General: Require source files to exactly match the original version

Put nuget in network path and try on another machine to create new project and add test nuget package and try to debug. You will see source code shown in temp location.