Source Link Flakiness in Visual Studio 2017 and 2019

7/10/2019 - Marco von Ballmoos

tl;dr: If MSBuild/Visual Studio tells you that "the value of SourceRoot.RepositoryUrl is invalid..." and you have no idea what it's talking about, it might help to add the following to the offending project and the error becomes a warning.


Microsoft introduced this fancy new feature called Source Link that integrates with NuGet servers to deliver symbols and source code for packages.

This feature is opt-in and library and package providers are encouraged to enable it and host packages on a server that supports Source Link.

Debugging Experience

The debugging experience is seamless. You can debug into Source-Linked code with barely a pause in debugging.

The only drawback is that you don't have local sources, so it's trickier to set breakpoints in sources that haven't been downloaded yet. When you had local sources, you could open the source file you wanted and set a breakpoint, knowing that the debugger would look for the file in that path and be able to stop on the breakpoint.

Also, Visual Studio's default behavior is to show all debugging sources in a single tab, so you don't even have all of the files open that you looked at when your debug session ends. If you hover the tab, you can figure out the storage location, but it's a long and not very intuitive path. Also, it only contains the sources that you've already requested.

Still, it's a neat feature.

Getting Pushy

However, Microsoft is doing some things that suggest that the feature is no longer 100% opt-in. The following error message cropped up in a project with absolutely no Source Link settings or packages. It doesn't even directly use packages that have Source Link enabled (not that that should make a difference).

There are actually three problems here:

  1. The compiler is complaining about Source Link settings on a project that hasn't opted in to Source Link.
  2. The compiler is breaking the build when Source Link cannot be enabled as expected.
  3. The error/warning messages are extremely oblique and give no indication how one should address them. (Another example is the warning message shown below.)

It's the second one that make this issue so evil. The issue crops up literally out of nowhere and then prevents you from working. The project builds. Even if I wanted Source Link on my project but it wasn't set up correctly, this is no reason to prevent me from running/debugging my product.

And, honestly, because of reason #3, I'm still not sure what the actual problem is or how I can address it with anything but a workaround.

Because, yes, I found a workaround. Else, I wouldn't be writing this article.

Things that Didn't Work

The first time I encountered this and lost hours of precious time, I "fixed" it by removing Source Link support for some packages that my product imports. At the time, I thought I was getting the error message because TeamCity was producing corrupted packages when Source Link was included. It was not a quick fix to open up a different solution, remove Source Link support and re-build all packages on CI, but it seemed to work.

Upon reflection and further reading, this is unlikely to have been the real reason I was seeing the message or why it magically went away. Source Link support in a NuGet server involves having access to source control in order to be able to retrieve the requested sources.

It's honestly still unclear to me why Visual Studio/MSBuild is complaining about this at build-time in a local environment.

The Workaround

Today, I got the error again, in a different project. The packages I'd suspected yesterday were not included in this product. Another, very similar product used the exact same set of packages without a problem.

Even though the issue Using SourceLink without .git directory isn't really the issue I'm having, I eventually started copying stuff from the answers into the project in my solution that failed to build.

Add the following to any of the offending projects and the error becomes a warning.


The ensuing warning? I can't help you there. I threw in a few other directives into the project file, but to no avail. I'm not happy to have a compile warning for a feature I never enabled and cannot disable, but I'm hoping that Microsoft will fix this sooner rather than later.

Sign up for our Newsletter