Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Re-added SourceLink support #703

Merged
merged 5 commits into from
Apr 13, 2020
Merged

Re-added SourceLink support #703

merged 5 commits into from
Apr 13, 2020

Conversation

bart-degreed
Copy link
Contributor

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 like c:\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:

  • Fixed package tags (must be single words, because tags are space-delimited in .nuspec)
  • Added description (shown in VS Package Manager UI)
  • Removed RepositoryType and RepositoryUrl, so they are calculated (and use the URL of my fork)

Closes #692.

Bart Koelman added 5 commits March 5, 2020 11:42
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](dotnet/sourcelink#255) 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](dotnet/sdk#2679), symbol server support is not working very well for numerous reasons.

So I reverted to [including the PDB](https://www.hanselman.com/blog/ExploringNETCoresSourceLinkSteppingIntoTheSourceCodeOfNuGetPackagesYouDontOwn.aspx) 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 like `c:\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:
- Fixed package tags (must be single words, because tags are space-delimited in .nuspec)
- Added description (shown in VS Package Manager UI)
- Removed RepositoryType and RepositoryUrl, so they are calculated (and use the URL of my fork)
@maurei maurei merged commit f458c48 into json-api-dotnet:master Apr 13, 2020
@bart-degreed bart-degreed deleted the sourcelink branch April 13, 2020 09:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

Restore SourceLink support
2 participants