Debug NuGet package with Azure Devops and Source L

问题:

I am trying to get SourceLink to work with a private NuGet package. I am running a netcore2.1 web application which references a netstandard2.0 NuGet package hosted on our Azure Devops NuGet feed.

Question 1: Does Source Link support .NET Standard packages?

I have followed the instructions in the guide here https://docs.microsoft.com/en-us/azure/devops/artifacts/symbols/setting-up-github-sourcelinking?view=vsts, which is basically:

1. Add the Index Sources and Publish symbols package to my Azure Devops build.

2. In Visual Studio, add our VSTS server as a symbols server

3. In Visual Studio, enable Source Link support. I also tried enabling Source server support.

The Build pipeline Publish symbols path appears to be working - in the logs I see: Succeeded processing D:\a\1\s\src\MyCompany.Core.Services.SnapshotClient\bin\release\netstandard2.0\MyCompany.Core.Services.SnapshotClient.pdb:

When I start debugging my application I see a bunch of output in the VS Output window: 'dotnet.exe' (CoreCLR: clrhost): Loaded 'C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App\2.1.4\Microsoft.AspNetCore.Hosting.dll'. Cannot find or open the PDB file.

For my NuGet package I see "Symbols loaded" which seems promising.

FWIW I do not see the prompt from Visual Studio that "Source Link will download from the internet".

When I debug and attempt to Step-In to my NuGet package, it just steps over it.

I then tried:

1. Headed over to https://github.com/dotnet/sourcelink and followed their instructions and installed the Microsoft.SourceLink.Vsts.Git package (Question 2 is that necessary?)

2. When that didn't work, I upgraded every darn package in my application, which forced me to install .NET Core SDK 2.1.403

3. Tried adding some stuff to the .csproj of my NuGet package, after trawling GitHub issues <PublishRepositoryUrl>true</PublishRepositoryUrl> <AllowedOutputExtensionsInPackageBuildOutputFolder>$(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb</AllowedOutputExtensionsInPackageBuildOutputFolder> and <DebugType>portable</DebugType> <ci>true</ci> Now my .nupkg includes .pdb files too, which weren't there before. Still doesn't help me step in debug though.

4. installed the sourcelink cli tools from https://www.nuget.org/packages/sourcelink/ and ran sourcelink print-urls on the .pdb from my .nupkg. Looks correct, I think? URLs are present.

5. Disabled indexing after seeing a comment https://github.com/MicrosoftDocs/vsts-docs/issues/1336#issuecomment-414415049 from @mitchdenny . Still doesn't work.

And now I'm stumped as to why it's not working.

回答1:

Question 1: Does Source Link support .NET Standard packages?

Yes. I successfully built a .NET Standard 2.0 library on Azure DevOps Pipeline, after which it was pushed to our private Azure DevOps Artifacts NuGet feed. Then, in a local project, I was able to step into the library (Visual Studio prompted me with a pop-up about downloading remote source code).

Here are the changes I had to make in the library's .csproj file:

<PropertyGroup>
  <PublishRepositoryUrl>true</PublishRepositoryUrl>
  <EmbedUntrackedSources>true</EmbedUntrackedSources>
  <AllowedOutputExtensionsInPackageBuildOutputFolder>
    $(AllowedOutputExtensionsInPackageBuildOutputFolder);.pdb
  </AllowedOutputExtensionsInPackageBuildOutputFolder>
</PropertyGroup>
...
<ItemGroup>
  <PackageReference Include="Microsoft.SourceLink.GitHub" Version="1.0.0-beta-63127-02" PrivateAssets="All"/>
</ItemGroup>

Question 2: is that [PackageReference to Microsoft.SourceLink.GitHub] necessary?

I'm not sure. The docs suggest it is. But I removed the reference, re-built on Azure DevOps, and was still able to step through the library. Perhaps it's necessary for different environments (I'm keeping it just in case).

FWIW:

• I'm debugging using Visual Studio 15.8.9
• My latest installed .NET Core SDK is 2.1.403
• My library's consumer is a .NET Core 2.1 executable
• I compiled my library using Cake, which I have call into dotnet msbuild

回答2:

I wrote a complete blog on how to do this using .NET Core & AzureDevops, but the steps should work for .NET Standard projects as well.

That said, some key takeaways that are missing from Microsofts documentation that you should know are:

• The project's debugging information needs to change from "Portable" to "Full"
• The AzureDevOps Nuget(restore, build, pack & push) need to use the .NET Core task.
• The .NET Core build task should have an argument "--configuration" that passes in the value "debug". Doing so generates the .PDB file
• The .NET Core pack task should use the "custom" command, with the custom command being "pack" and have the following arguments: "--include-symbols -v d" and a "-c" that passes in the value "debug". Doing so tells the pack command to include the .PDB file in the package.