GTD fails for subsequent symbol navigation with SourceLink

[AliveDevil]

But is there any workaround right now in 17.3 to disable navigation to source link? The setting "Always use default symbol servers for navigation" that you mentioned previously doesn't seem to work - so it doesn't disable navigation to source link files.

The reason I'm asking is that since updating to 17.3 I often get a "Cannot navigate to the symbol under the caret." error message box when navigating in ASP.NET Core source code. I never had this problem with metadata navigation, but now with source link navigation it happens way too often so that navigation in VS is not usable any more.
(Btw, that error is not reproduceable reliably. Sometimes a VS restart allows me to navigate to classes that didn't work just a moment before. And then it again fails on the second try on the same class...)
Originally posted by @cremor in #59717 (comment)

7UizGAwZfO.mp4

sl-gtd.zip

Originally posted by @AliveDevil in #59717 (comment)

[cremor]

Also worth noting: There no fallback to metadata if this happens, altough there should be according to @davidwengier in #59717 (comment). So I think there should be two fixes here:

• Fix the bug that prevents navigation to source link.
• Fix the fallback to navigation to metadata if navigation to source link fails for any reason.

[davidwengier]

It's unlikely that the fallback is the thing failing here. What it looks like is happening is that we are failing to find the symbol that we need to navigate to, so we can't find any Source Link info for that symbol, but we equally can't fallback to metadata for that symbol. ie, we don't know anything about the type being navigated to, include the assembly it comes from, so there is no metadata available.

[davidwengier]

@cremor just to confirm, it looks like in the video that the first navigation from inside a Source Link file works, but the second time fails? Is that accurate?

[AliveDevil]

That is accurate, indeed. First navigation works, then fails on repeated tries.

GTD into Source Link, select symbol, GTD, works fine.
Go back to user code, GTD, then select a symbol and GTD again and it fails.

[davidwengier]

Thanks both for the reports, this turned out to be a gap in Go To Definition not doing some mapping that it should be doing (and that Find References etc. already do). It only shows up in Source Link/Embedded because in that system we're a bit nicer with things, and reuse previously created (in memory) projects and previously downloaded source files. Metadata creates a new (in memory) project every time you navigate, so it was immune to this, which is why nobody noticed until now. Will have a fix up soon, hopefully in time for 17.4 P2

[cremor]

@davidwengier

@cremor just to confirm, it looks like in the video that the first navigation from inside a Source Link file works, but the second time fails? Is that accurate?

Yes, that's also what I see.

Will have a fix up soon, hopefully in time for 17.4 P2

Thanks, but any chance to get this fix in 17.3.x?

[davidwengier]

I'm afraid not, this won't meet the bar for a servicing release.

[cremor]

How are we supposed to work with GTD then in 17.3? It seems like there is no workaround other than restarting VS?

[davidwengier]

If you disable all of the symbol servers in the debugging options, and turn off "Use default symbol servers" in the text editor, then that will effectively work around the issue if your dependencies aren't embedding their sources in embedded PDBs.

But yes, you're right, there isn't a good workaround. Unfortunately that doesn't mean it meets the bar for servicing, especially since this isn't a general breakage in Go To Definition, but only affects it when the Go To Definition action is instigated from a document that comes from a previous action, and after the second time. That's reasonably specific :)

[cremor]

If you disable all of the symbol servers in the debugging options, and turn off "Use default symbol servers" in the text editor, then that will effectively work around the issue if your dependencies aren't embedding their sources in embedded PDBs.

I've already tested this, it doesn't work for ASP.NET Core. So I assume ASP.NET Core has embedded sources?
That will be a really annoying time until 17.4 😢