git nuget visual-studio-2022 nuget-package sourcelink

Visual Studio insists downloading source files from GIT Repo for local Dev-builds in local NuGet-feed

Setup

We have internal NuGet packages consumed in other solutions, that we would like to package and debug locally in those other solutions, before we push both the code changes to Git and NuGet package to our shared source.

See my previous StackOverflow question and answer for more context: Local NuGet Package Source throws Error "Object reference not set to an instance of an object."

Problem

Until recently this workflow has worked wonderfully, however now VS always looks for the source code via our GIT-Repo. So if I just want to change something and debug locally in other solutions, I would have to push to GIT every time I change a single character such that I can debug with the correct source file. For pure dev builds, this is unacceptable imho. I understand that this behaviour is part of Source Link. And it's a great feature, however for iterative dev builds it's not a good fit.

What changed?

I cannot really tell. That is what is so nebulous to me. I have for sure updated VS from time to time since I last worked on the NuGet package. I do not remember updating NuGet, but I would figure that this has updated along with it. Otherwise, no changes were made to the build and packaging process for local testing.

What I have tried but has not worked

Disable "SourceLink"
Disable "Just My Code"
Remove git repo information from the local test package.
- On this note I tried to remove it, but either it would ignore my configuration in .nuspec and .csproj or if I removed it from the package manually afterwards, it would somehow still know where to look for the GIT-repo.
Create package without symbols.
Use the new package format .snupkg.
Include source code directly inside the .symbols.nupkg or .snupkg.
Disconnecting from the network. My hope was that the download would fail and it would give a prompt to look elsewhere.

What I have tried and did (somewhat) work

Use the disassembled version of the dll. While that does work, the source code won't look the same and some variables values cannot be checked during debugging.
Once a file was downloaded from Git via Source Link, I can copy and paste the updated source code into it and then debug. VS even understands that the downloaded source code from GIT is out of sync with the assemblies, and that the copied source code hash matches.
- However, this is a manual per file operation and I would rather not have to do that every time or at least automate it ahead of testing and debugging.
Reference the required assemblies directly
- However, I have to do this for each subproject in the solution and is again a lot of manual work. If at least the referenced assemblies were transitive, that would help a lot.

What I would want

Preferably, I want to incl. the matching source code or at least a local path to source code inside the nuget package and for VS to automatically pick that up. And only once I am satisfied with the end result, commit my package and code changes to Git and shared NuGet source.
Somehow tell VS to not use SourceLink or temporarily configure SourceLink to not go to our repository and instead look elsewhere. So far, disabling it doesn't change the behaviour and instead just prompts me to enable it again.

In the end, I just really hope I don't have to either constantly push untested changes or having to do a bunch of manual changes, just because I want to test and debug from within another dependent solution.

Solution

Took me a while to figure it out, but by using multiple different answers from StackOverflow I was finally able to recreate the desired behaviour.

To enable me to debug a package from a local NuGet feed I had to add the following section to my .csproj. After doing so VS 2022 would locate the correct source files.

<Project Sdk="Microsoft.NET.Sdk">
  [...]
  <PropertyGroup>
    <!-- Map 'Release' / 'Debug' environments to boolean values -->
    <IsReleaseBuild>false</IsReleaseBuild>
    <IsReleaseBuild Condition="'$(Configuration)' == 'Release'">true</IsReleaseBuild>
    <IsDebugBuild>false</IsDebugBuild>
    <IsDebugBuild Condition="'$(Configuration)' != 'Release'">true</IsDebugBuild>

    <!-- Required for both Release and local Dev-Builds -->
    <ContinuousIntegrationBuild>false</ContinuousIntegrationBuild>
    <DeterministicSourcePaths>false</DeterministicSourcePaths>
    <EmbedUntrackedSources>true</EmbedUntrackedSources>
    <DebugType>Embedded</DebugType>

    <!-- Required for SourceLink when publishing NuGet packages to shared feed online. -->
    <PublishRepositoryUrl>$(IsReleaseBuild)</PublishRepositoryUrl>
    <IncludeSourceRevisionInInformationalVersion>$(IsReleaseBuild)</IncludeSourceRevisionInInformationalVersion>

    <!-- Required for Debugging with packages in local NuGet feed -->
    <GenerateDocumentationFile>$(IsDebugBuild)</GenerateDocumentationFile>
    <EmbedAllSources>$(IsDebugBuild)</EmbedAllSources>
  </PropertyGroup>

</Project>

You can verify the behaviour by opening the files from the "External Sources"-section during debugging:

The file-tab shows a small lock-icon.
The containing folder will be %AppData%\Local\Temp\.vsdbgsrc.

In case the symbols aren't loaded when starting the Project, try a full solution rebuild.
If that still doesn't load the correct symbols you can go to "Tools > Options > Debugging > Symbols" and change to "Search for all module symbols unless excluded", then rebuild the solution again.

Resources which helped me find a solution:

I have tried different combinations of configuration properties before, however it appears to me that some properties are quick to override others by default, if they are not being actively disabled. At least to me the documentation seems fragmented and generally hard to find, if you aren't exactly sure what you are looking for.