Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Getting this to work was quite a challenge.
I started out with the minimal example described at https://blog.jetbrains.com/dotnet/2020/02/03/sourcelink-consuming-apis-nuget-dependent-code/ and the guidance at https://github.com/dotnet/sourcelink/. This creates a .snupkg (containing symbols) next to the .nupkg, both of which need to be uploaded to nuget.org. At the moment, nuget.org is the only package registry that supports this. It does not work for local feeds, AppVeyor or any other registry (https://stackoverflow.com/questions/54211644/publish-snupkg-symbol-package-to-private-feed-in-vsts). And requires an internet connection during debug, as there is currently no command to fetch all symbols upfront.
After uploading to NuGet.org, stepping into sources did not work on my machine (VS Debug settings: Enable Source Link support checked and Enable Just My Code unchecked). Then I enabled the NuGet.org Symbol Server, which started downloading symbols for all .NET Core packages during my debug session, which took forever so I aborted.
It turned out that in the past, SourceLink worked by including the PDB in .nupkg, but guidance was changed to use the nuget.org symbol server instead. I installed the sourcelink global tool (https://www.meziantou.net/how-to-debug-nuget-packages-using-sourcelink.htm) and ran it with the
test
switch, which failed and reported that AssemblyInfo.cs could not be found. This sounds reasonable, because the file is auto-generated by the .NET Core build chain. As discussed here, symbol server support is not working very well for numerous reasons.So I reverted to including the PDB instead of using symbol server (using
$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb</AllowedOutputExtensionsInPackageBuildOutputFolder>
) and setup a local nuget feed. This worked, but only because the DLL and PDB contained hardcoded paths to my sources on disk. There was no prompt to download sources from GitHub. Renaming the JADNC directory or adding<DeterministicSourcePaths>true</DeterministicSourcePaths>
(which changes paths likec:\source\repos\JsonApiDotNetCore\...
to\_\JsonApiDotNetCore\...
) broke the experience. I had to manually browse to the PDB file on disk (via Modules, Load Symbols) to be able to step into sources again.The only way I got this working without intervention was to embed the PDB inside the DLL, using
<DebugType>embedded</DebugType>
. Note you need to push first, so that the commit hash stored in .nupkg exists on GitHub. And have Enable Just My Code unchecked in VS Debug settings.Other changes in this PR:
Closes #692.