Skip to content

Commit

Permalink
Re-added SourceLink support (#703)
Browse files Browse the repository at this point in the history
* Re-added SourceLink support

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)

* Removed unneeded folder in project file

* Empty commit to restart TravisCI

* Empty commit to restart TravisCI
  • Loading branch information
nicolestandifer3 committed Apr 13, 2020
1 parent 5d2114b commit a42b916
Showing 1 changed file with 4 additions and 4 deletions.
8 changes: 4 additions & 4 deletions src/JsonApiDotNetCore/JsonApiDotNetCore.csproj
Original file line number Diff line number Diff line change
Expand Up @@ -6,15 +6,14 @@
</PropertyGroup>

<PropertyGroup>
<PackageTags>jsonapi;dotnet core;emberjs;ember</PackageTags>
<PackageTags>jsonapi;json:api;dotnet;core</PackageTags>
<Description>A framework for building json:api compliant web APIs. The ultimate goal of this library is to eliminate as much boilerplate as possible by offering out-of-the-box features such as sorting, filtering and pagination. You just need to focus on defining the resources and implementing your custom business logic. This library has been designed around dependency injection making extensibility incredibly easy.</Description>
<PackageProjectUrl>https://github.com/json-api-dotnet/JsonApiDotNetCore</PackageProjectUrl>
<PackageLicenseExpression>MIT</PackageLicenseExpression>
<PackageRequireLicenseAcceptance>false</PackageRequireLicenseAcceptance>
<RepositoryType>git</RepositoryType>
<RepositoryUrl>https://github.com/json-api-dotnet/JsonApiDotNetCore</RepositoryUrl>
<PublishRepositoryUrl>true</PublishRepositoryUrl>
<EmbedUntrackedSources>true</EmbedUntrackedSources>
<AllowedOutputExtensionsInPackageBuildOutputFolder>$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb</AllowedOutputExtensionsInPackageBuildOutputFolder>
<DebugType>embedded</DebugType>
</PropertyGroup>

<ItemGroup>
Expand All @@ -25,6 +24,7 @@
<PackageReference Include="Ben.Demystifier" Version="0.1.6" />
<PackageReference Include="Humanizer" Version="2.7.9" />
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="$(EFCoreVersion)" />
<PackageReference Include="Microsoft.SourceLink.GitHub" Version="1.0.0" PrivateAssets="All" />
<PackageReference Include="Newtonsoft.Json" Version="12.0.3" />
<PackageReference Include="System.ValueTuple" Version="4.5.0" />
</ItemGroup>
Expand Down

0 comments on commit a42b916

Please sign in to comment.