Support for "classic" .NET project

We are running an on-premises devops server which creates nuget packages from our modules. All projects are “classic” .NET projects (targeting 4.7.2). In order to enable source link support we added the following packages to our modules:

  <package id="Microsoft.Build.Tasks.Git" version="1.0.0" targetFramework="net472" developmentDependency="true" />
  <package id="Microsoft.SourceLink.AzureDevOpsServer.Git" version="1.0.0" targetFramework="net472" developmentDependency="true" />
  <package id="Microsoft.SourceLink.Common" version="1.0.0" targetFramework="net472" developmentDependency="true" />

Furthermore the project files (*.csproj) were modified like this:

  <PropertyGroup>
    ...............
    <PublishRepositoryUrl>true</PublishRepositoryUrl>
    <EmbedUntrackedSources>true</EmbedUntrackedSources>
  </PropertyGroup>

  <ItemGroup>
    <SourceLinkAzureDevOpsServerGitHost Include="XXX" VirtualDirectory="/" />
  </ItemGroup>

In another repository we have projects with references to these NuGet packages. When running in a debugger the symbols are loaded but the sources are not found. So we are a little bit lost here. For me it is not really clear what steps have to be done in order to use SourceLink support in “classic” .NET projects. By the way the debug information (pdb) will be put to a network share during the builds.

[bjuraga]

Thanks @MTantos1, i expected that SourceLink drops the need for pdb files but from your explanation it is clear that it “just” changes file paths and has a file provider per repo type. Would be nice if the core part of your explanation on how SouceLink works would be part of the official docs and prevent misconceptions caused by the marketing team. The quote i posted above mentions nothing about pdb.

[MTantos1]

@bjuraga: What source link does is allow you to view the source, via a repository, when debugging. Without the symbol files (PDBs) it would be impossible for the debugger to link to anything other than machine code (or MISL). The metadata, as you call it, is stored in the symbol file, so without it SourceLink has no chance of doing anything.

When you build a project the compiler outputs a symbol file, which is basically a map from the executable (likely a dll) to the corresponding source. The problem with this is that the symbol file will refer to the source file location on the build machine, which may not be the same machine you are trying to debug from. So when you try and debug the debugger will try and find the source file at a location that likely doesn’t exist, or find a modified version of the source.

What SourceLink does, is effectively re-write the symbol file, so that the symbol file no longer maps to a path on the build machine, but to a repository url. So, with the proper tooling, when you attach the debugger, rather than looking for files on your local machine it looks for the source on GitHub, etc.