Home: 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.
    
    
    
  
  
  • 
    
    
    1. 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 https://github.com/NuGet/Home/issues/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.

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

2. 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.

[jnm2]

We also have evidence that a majority of users won't debug into third party components

What can we do to change this culture though, and what would it look like when we get there? I see that change as a worthy end goal which is why I'm so thrilled you're making this a focus.

[aluhrs13]

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?

There's already a solution pretty much available for this. SymChk has the concept of "manifest" files for offline scenarios - https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/using-a-manifest-file-with-symchk

[dotMorten]

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

That would turn it on for all packages. That could end up being a lot of stuff to restore.

I'd prefer having a per-package symbol setting. How about doing it in the properties window (which would set a property on the package reference)?

[bording]

While I think that making symbol servers easier to use is a good thing, I really do wish the "include the symbols in the main package" approach was becoming the preferred recommendation here, especially given the size reduction of portable PDBs.

When a package author includes SourceLinked PDBs directly in the package, then a lot of great debugging scenarios light up automatically without the consumer of the package having to do anything special at all.

It also makes it easier to deploy those PDBs into production, which means that any exceptions logged in production will include stacktraces that have line numbers.

[SeanFeldman]

A few Microsoft teams have adopted SourceLinked PDB approach and it works great for the customers. 👍 to that to become the preferred approach.

[ctaggart]

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.

@diverdan92 Until the tooling is ready in a few or more months, can projects like https://github.com/aspnet/Universe/issues/131 get the blessing to ship portable pdb files? It works today with SourceLink 2. With the plan in place, we can switch to the new tooling when it becomes available. SourceLink 3 will be a part of the new tooling.

[diverdan92]

@ctaggart - you mean for them to ship portable .pdb files in the .nupkg? There is nothing blocking anyone from doing that today. When you do a package restore, the entire contents of the .nupkg will be downloaded and cached at the NuGet package cache. This experience isn't impacted from this spec - I just was calling out that we won't index those symbols to our service unless they are explicitly added to the .snupkg.

[tmat]

@diverdan92 Since there is a clear interest in including Portable PDBs in nupkgs I wonder if we could relax that restriction and provide both options. By default we would generate nupkg and snupkg, but if the package author wants to opt into including PDBs in nupkg and not build a snupkg at all then why not index such PDB?

[diverdan92]

@tmat - we will figure out a way to best provide this solution.

With this in mind, we do recognize some members of the community asking for improved embedded PDB support in the .nupkg and will be looking for feedback to best solve this problem.

It may just be a flag on dotnet / nuget pack command. Any suggestions?

Regarding .pdb indexing, we want to make it an explicit action. At package ingestion time we will have additional validation on .snupkgs that are different than .nupkgs. There will be different requirements for having .pdbs ingested into the symbol server, hence the requirements.

[clairernovotny]

@tmat I agree that they should be indexed, but the question is around security and what should be indexed from inside the nupkg?

Files may live outside of \lib and \ref, for example, what do you do with files in the \tools for tools packages? What about packages that have files in build\_foo\ and include them dynamically in included targets?

Some of those packages may have 3rd party pdb's as the result of a publish. Do you include those or ignore them? How do you know? What if those 3rd party pdb's don't meet your security requirements? That could very well happen with the contents of a \tools folder.

Things to think about.

[tmat]

@onovotny Definitely need to think about that. I'd enumerate all .dlls and .exes in \lib, \ref, \tools directories (recursively). If the dll/exe file has a matching associated PDB next to it it would be a candidate for indexing. The matching would be based on PDB ID (GUID) and a strong crypto hash of the PDB content. Non-matching PDBs would be ignored.

I don't think indexing 3rd party PDBs is a problem, but would need to think about it more.

[clairernovotny]

@tmat Imagine the scenario that there's foo.dll and foo.pdb in the \tools directory as a 3rd party lib that was brought in during publish. Now what if foo.pdb only has a sha1 hash. Do you reject the entire package or just skip that one symbol? What if that 3rd party one has source server v1 commands in it?

It's easier to reject a snupkg if any of the packages are bad since it's an explicit decision what to include in that file. It's harder in a nupkg.

[tmat]

@diverdan92
The following will include Portable PDB in nupkg today:

  <PropertyGroup Condition="'$(DebugType)' == 'portable'">
<AllowedOutputExtensionsInPackageBuildOutputFolder>$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb</AllowedOutputExtensionsInPackageBuildOutputFolder>
  </PropertyGroup>

So one option would be to do this automatically if some new property is set, we can call it e.g. IncludeSymbolsInNupkg.

[tmat]

@onovotny I'd just ignore that one pdb. The rules for .snupkg would be stricter - no pdb would be ignored there.

[clairernovotny]

Is .snupkg the final extension or is that still being decided?

[diverdan92]

It's final when it's implemented 😉. We haven't heard any push-back on it so far, though. When we have a more technical spec ready, we'll have this finalized.

[maartenba]

One question: what is there to index for .snupkg? The PDB contains either embedded sources, or a SourceLink pointing to a repo out there. Windows PDB need indexing, for the new ones all that is needed is hosting the .pdb files, right? (barring extracting the PDB and assembly guid to match them up)

[diverdan92]

@maartenba the .pdb itself will be indexed on a symbols server. We aren't indexing source (as you call out, it's either found via SourceLink or it's embedded), we are just indexing the symbols so when you add the NuGet.org Symbol Servers as a source in your IDE, symbols can be automatically found and downloaded.

Not sure I understand your second question? What do you mean all that is needed is hosting the .pdb files?

[maartenba]

So in essence you repeated my remark - barring ..... is the stuff you described - nothing to see here, carry on :-)

[mungojam]

Our main issue with debugging into our internal nuget packages is that they are optimised by the compiler so some lines get jumped over. We would love a way that we could publish a Debug version of every package (internally) and be able to switch between it and the Release version easily.

This would increase storage requirements significantly, though maybe it could have a clever delta format that would sit in the symbols package.

[diverdan92]

@mungojam - are your projects using the Packages.config model of referencing packages, or PackageReference? One thing you can do with PackageReference is create both a debug and release version of your package (e.g. Foo.nupkg and Foo.Debug.nupkg), and then conditionally include those packages depending on the configuration of your project.

Check out adding a PackageReference condition.

[mungojam]

@diverdan92 - great idea, maybe I could put that as a build step on the packages so that it automatically did the same for transitive dependencies when switching the top one to debug mode. Otherwise it would need lots of manual effort from developers in my team.

We haven't yet converted to PackageReference, partly because of this issue I raised regarding default behaviour around transitive dependencies. I'm trying to figure out a workaround where I can automatically figure out which down-level packages actually need to be added as references in consuming projects.

[sharwell]

@diverdan92 I like the idea in theory, but I wouldn't want to publish two packages with different names. With the work to improve symbol navigation and debugging experiences, non-optimized binaries will be as important to this feature as PDBs, sources, and "snupkg".

[jnm2]

Non-optimized binaries- hmm. But then there's the danger that the debug binaries have different behavior, so stepping into source of such a library would make a new kind of heisenbug possible.

[mungojam]

@jnm2 occasionally that could cause a problem but the vast majority of our cases we are either debugging in order to:

a. Better understand the behaviour of a package we are using
b. Diagnose a regular bug that's present in release or debug mode

In both these cases, it's far better to be able to debug through non-optimised code, same way as code maps in JS allow people to debug through non-minified javascript.

[jnm2]

I think with JS code maps, it's still the minified code which is executed and the debugger positions are merely mapped to the original source. Looking it up seems to confirm this? In any case, I'd want the option to step through the release binary and source. Imagine stepping through this code:

#if DEBUG
            BypassCheckForDevelopment();
#else
            var thingToInspect = GetInterestingThing();
            MethodToStepInto(thingToInspect);
#endif

I don't want to be forced to step into every #if DEBUG section and prevented from stepping into any #if !DEBUG section.

[mungojam]

Yeah, I guess with JS the difference is that presumably there is no optimisation going on in the minification so both our desires are satisfied by it's behaviour.

You're right, I'd want an easy way to switch between the behaviours which is another argument for something built in.

It could be achieved manually by having a third build configuration that had debug flag set at top level but pulled in release versions of down-level packages with pdbs. That would be annoying to have to do for every tool we have.

[diverdan92]

@mungojam - these are great points. I think there are optimizations we could do around debug binaries in NuGet packages as well. While absolutely related to this issue and spec, it's a slightly different topic when considering solutions. We still have goals regarding performance of NuGet as a platform, and so we would be hesitant to include both debug and release binaries in the same .nupkg - something that would benefit an important group of developers, but would have an impact on _everyone_, regardless of whether or not they plan to debug into debug binaries.

Just some early brainstorming, but perhaps a solution could behave like this? Let me know what you think:

• Client tooling updates to pack to support a /BuildDebugPackage flag that produces two .nupkgs (debug and release)
• Additional client restore tooling to support a flag on the consuming side that would attempt to restore both Debug/Release packages on package restore, and load the different assemblies at runtime based on project configuration(s)?

This is just me jotting some ideas down, but I'd be interested to hear your feedback. With a solution like the above, the .snupkg features would just carry over to support debug packages as well (so both debug and release pdbs could be indexed).

I think what is discussed in this spec should be future proof to solve the debug binaries problem as well, while still maintaining optimal performance in NuGet, but please do let me know if you disagree?

[mungojam]

@diverdan92 thanks Dan, those ideas do sound like they would answer it nicely. I agree that the debug binaries shouldn't end up in the main nupkg, though for our internal packages we wouldn't mind that.

Additional client restore tooling to support a flag on the consuming side that would attempt to restore both Debug/Release packages on package restore, and load the different assemblies at runtime based on project configuration(s)?

Having a new flag would help with @jnm2's point because you could then easily have a Debug project config that actually pulled in release packages and a FullDebug one that pulled in debug packages, or something like that.

I like the direction this is all going :)

[vancem]

cc: @vancem

[dotMorten]

Just a note: My C++ symbols are over 500mb per architecture. So it might be worth considering being able to split the symbol packages up per architecture, so you only have to download the one you care about.

[diverdan92]

@dotMorten - the symbols are indexed on a symbol server after the .snupkg is uploaded to nuget.org. When debugging your application, on the symbols that are applicable to the running process should be downloaded from the symbol server. The .snupkg that you uploaded will be bigger, but it shouldn't impact how symbols are downloaded. Does this sound like a problem?

[rohit21agrawal]

@tmat what's the debugging experience with optimized binaries and portable PDBs? I would imagine it would be good to get a call stack , but not much apart from that? Or am I totally wrong?

I am trying to think if there is a need to have a scenario around non-optimized binaries in the snupkg.

[vancem]

The nice thing about manage code is that you can recompile it on the client and you can actually tell it not to optimize. See

https://blogs.msdn.microsoft.com/vancem/2017/12/20/update-debugging-through-the-net-core-framework-v2-0-3-windows/

And if you want to do this in VSCode, here are instructions https://github.com/OmniSharp/omnisharp-vscode/wiki/Debugging-into-the-.NET-Framework-itself

When you do this, you are debugging non-optimized code so you get a very good experience.

Obviously this can't work if you are debugging an issue that only reproduces on optimized bits, but that is an unusual case. It also does not work if you attach your debugger (since the methods have already been compiled and it won't do it again), but it does work for an important case.

[mungojam]

@vancem thanks! I'll need to try that with our own libraries. It sounds like just ticking Suppress JIT optimization on module load. in VS settings or "suppressJITOptimizations": true in VS Code would be enough.

I hadn't realised that the optimisations were only happening in the JITter, not the original compile.

[mungojam]

We tried the 'suppress JIT optimization' trick with a .net framework library today. It helped, but there were still some variables that weren't exposed to the debugger so I guess there are still some optimisations going on. So it would still be useful to have a story around this even if it's just better guidance.

[vancem]

To my knowledge, the combination of COMPLUS_ZapDisable and Suppress JIT Optimization should be 'perfect' in the scenarios where they work (that is you started the process that environment variable and attached to a debugger suppressing JIT optimization).

If it is not that way, you should at least describe the simplest case where it is not so we can have a look as to why. I might just be misunderstanding, and it is less perfect that I think, but we can only figure that out with specific examples to dig into.

[mungojam]

ok, that's useful to know. I will try and come up with a minimal example to see. I admit we didn't bother with COMPLUS_ZapDisable because I got the impression that was only relevant for NGENed DLLs which ours aren't.

[vancem]

You are correct that COMPLUS_ZapDisable only matters for framework things (that were crossgened). I was assuming you were having problem debugging into framework code.

I am more surprised by your result now. (Or maybe I don't understand your scenario). With 'Suppress JIT optimization, you SHOULD get the same debugging experience as when you debug your own 'debug' code.

[mungojam]

We've discovered what was happening, Resharper was decompiling the code that we were debugging into or getting it from somewhere else rather than from TFS. When we made sure that VS was pulling the sources we were then able to observe all variables in the debugged code.

Thanks again, the requirement to create debug versions of our packages may have just disappeared for us :) Wish I knew about this setting 5 years ago!

[mungojam]

It seems there is a big regression with the new project-system (not when just changing to PackageReference). We include our .pdb files inside the appropriate lib folder of our packages. With the old project system, they get automatically output to the bin directory of our tools for easy debugging.

With any tools using the new project-system none of them are not getting output, just the pdb from the tools themselves.

Is this a known functionality change?

now raised: https://github.com/dotnet/project-system/issues/3524

[jnm2]

@mungojam There is an existing issue: https://github.com/dotnet/sdk/issues/1458 (workaround).

[krispenner]

Additional client restore tooling to support a flag on the consuming side that would attempt to restore both Debug/Release packages on package restore, and load the different assemblies at runtime based on project configuration(s)

@diverdan92 I would like to see this in VS - is there a discussion with the VS team for this that you are aware of?

Currently, you cannot step-in to an async method built in release mode - some optimization prevents this, it just steps over it every time. Your suggestion would make this very easy when debugging referenced packages with async methods which is pretty common. See https://github.com/dotnet/roslyn/issues/13850

One thing you can do with PackageReference is create both a debug and release version of your package (e.g. Foo.nupkg and Foo.Debug.nupkg), and then conditionally include those packages depending on the configuration of your project.

I was initially thinking along these lines as well and came across this issue when googling what others were doing to support debug builds in packages. Will probably go this path until better support for debug builds is added. The editing my csproj files by hand to add conditional package references is a drawback for me.

[dotMorten]

@tmat

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.

No I did not mean submodules. Each repo builds different DLLs, and the nuget packaging assembles them all. In my case one repo for one of C++ DLLs (multiple architectures) a another repo for a .NET AnyCPU DLL + a C++ (Multi-architecture) DLL. We don't use submodules, since that requires us to daily update the commit ID, so the dependency can be referenced by master daily or log onto a tag when we start stabilizing.

[tmat]

@dotMorten In that case each repo is responsible for generating SourceLink for the binaries it produces and embedding it into the PDBs corresponding to these binaries.

[dotMorten]

@tmat SourceLink appears to be a Roslyn feature and doesn't help PDBs for C++ libraries.

[tmat]

@dotMorten We have implemented support for Source Link in C++ as well. Let me check when is the feature expected to be released.

[tmat]

@dotMorten VS 2017 Update 8.

[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 [e-mail] wrote:

Does it work in Visual Studio Code?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/NuGet/Home/issues/6104?email_source=notifications&email_token=AGVIXYRMY2FQ3KM5LSOXBB3QQKRW3A5CNFSM4EA3DIV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECHRKBQ#issuecomment-546247942, or unsubscribehttps://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 "libuap10.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.