Roslyn: Goto Definition goes to [from metadata] view when target project is SDK and has AssemblyName set

[vsfeedback]

VSF_TYPE_MARKDOWNCreate a new Solution with a .NET Framework Console Application.
Add a new .netstandard class library to the solution and reference it from the Console Application.
Change the class library csproj to the following:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netstandard2.0</TargetFramework>
    <AssemblyName>Shared</AssemblyName>
  </PropertyGroup>

</Project>

Use this code in the Console Application

using ClassLibrary1;

namespace ConsoleApp12
{
    class Program
    {
        static void Main(string[] args)
        {
            new Class1();
        }
    }
}

Build and then press F12 on new Class1(), Visual Studio will navigate to the [from metadata] view.
Remove the <AssemblyName>Shared</AssemblyName> from the class library, build and try F12 again, this time it will navigate to the source directly

_This issue has been moved from https://developercommunity.visualstudio.com/content/problem/481936/goto-definition-goes-to-from-metadata-view-when-ta.html
VSTS ticketId: 814002_
_These are the original issue comments:_

Visual Studio Feedback System on 3/7/2019, 05:58 PM (119 days ago):

We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.

Visual Studio Feedback System on 3/8/2019, 05:51 PM (118 days ago):

This issue is currently being investigated. Our team will get back to you if either more information is needed, a workaround is available, or the issue is resolved.

_These are the original issue solutions:_
(no solutions)

[Spongman]

i'm seeing the same issue. i have a solution with a mix of framework, web, netstandard & core console projects.

when visual studio is starting up, and the background tasks are still running, f12 works fine across framework projects. however, at some point during the background tasks running f12 stops working and starts showing the 'from [metdata]' source instead.

this happens every time, without fail. it breaks 'go to definition', 'go to implementation', 'find all references', refactorings including symbol renaming, the codelens reference counts, etc...

I have a 2GB notepad now.

[Spongman]

ok, here's a repro:

bug.zip

• open the solution
• restore & build all
• open Program.cs
• close solution
• open solution
• immediately 'goto definition' on Method() symbol in Program.cs, if it works go back and keep trying until it stops working (usually after background tasks have finished)

[Spongman]

was anyone able to repro this?

[destumme]

I encounter this exact issue as described by @Spongman, but only when navigating from csproj's that contain unit tests (MSTest). At one point I had it working by disabling Live Unit Testing, but that seems to no longer be the case.

[CyrusNajmabadi]

and a year goes by and crickets. come on guys, this is a regression in a major productivity feature of your product that's been there since .NET began. can you please, at least, respond that you have attempted to repro this?

This has not been assigned and has no responses from a team member. So I think it's a safe assumption to say that no one has attempted to repro this. That said, it sounds like it's happening to a few people and a repro gas been given, so I don't think we'd but a lot with someone else doing that.

Note: this issue is up for grabs. This means that while it's not a high pri for us (and is this on our backlog), we would likely take a community fix it this was important enough for you that you provided a contribution yourself. Thanks! :-)

[Spongman]

(( can i please get someone to at least attempt to repro this? i went to the effort to create a minimal repro case. can't someone at microsoft at least do me the common decency of triaging it? does nobody care about QA there any more? ))

So, i Just noticed another weird thing. when Visual Studio opens the "[from metadata]" file, that file lists the source assembly, like this:

````

region Assembly Data, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null

// C:\work\MySolution\LibProject\bin\Release\LibProject.dll

endregion

````

even if i delete that .dll, hitting F11 on a reference to a symbol in that project _still_ opens the same metadata file with the _same_ source .dll listed in the header - even though that .dll file no longer exists.

doing an 'Open Containing Folder' on that metadata file shows some files in %TEMP%\MetadataAsSource\.... after deleting that whole directory, the _same_ metadata file is generated, against from a non-existent dll.

it turns out visual studio is crashing:

````
Error Information
AppInsightsEvent Name = vs/ide/vbcs/nonfatalwatson
Description = Microsoft.CodeAnalysis.Editor.CSharp.DecompiledSource.CSharpDecompiledSourceService.PerformDecompilation
TelemetrySession = '14b9c204-35b3-4dbf-ade9-a4178b642520' Started = True OptIn=True IsInitialized = True Cloned = False
WatsonEventType = VisualStudioNonFatalErrors2
UTC time = 2020-10-06T17:57:29

Exception:
System.IO.DirectoryNotFoundException
Could not find a part of the path 'C:\work\MySolution\LibProject\bin\Release\LibProject.dll'.
System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access)
ICSharpCode.Decompiler.Metadata.PEFile..ctor(String fileName, PEStreamOptions streamOptions, MetadataReaderOptions metadataOptions)
Microsoft.CodeAnalysis.Editor.CSharp.DecompiledSource.CSharpDecompiledSourceService.PerformDecompilation(Document document, String fullName, Compilation compilation, String assemblyLocation)
Microsoft.CodeAnalysis.Editor.CSharp.DecompiledSource.CSharpDecompiledSourceService.d__3.MoveNext()
System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
Microsoft.CodeAnalysis.MetadataAsSource.MetadataAsSourceFileService.d__11.MoveNext()
````

and spawning WerFault.exe, so you should check your telemetry.

again, the source for that symbol is right there in that project.

don't know if this is relevant, found in %TEMP%\servicehub\logs:
10/03/2020 12:17:12 Pacific Standard Time: Error : 1 :[devenv:5024] Unexpected exception: System.IO.FileNotFoundException: Could not find file 'c:\vs16\Common7\IDE\CommonUtils'. File name: 'c:\vs16\Common7\IDE\CommonUtils' at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost) at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access) at ICSharpCode.Decompiler.Metadata.PEFile..ctor(String fileName, PEStreamOptions streamOptions, MetadataReaderOptions metadataOptions) at Microsoft.CodeAnalysis.Editor.CSharp.DecompiledSource.AssemblyResolver.<Resolve>g__MakePEFile|4_0(IAssemblySymbol assembly) at Microsoft.CodeAnalysis.Editor.CSharp.DecompiledSource.AssemblyResolver.Resolve(IAssemblyReference name) at ICSharpCode.Decompiler.TypeSystem.DecompilerTypeSystem..ctor(PEFile mainModule, IAssemblyResolver assemblyResolver, TypeSystemOptions typeSystemOptions) at ICSharpCode.Decompiler.TypeSystem.DecompilerTypeSystem..ctor(PEFile mainModule, IAssemblyResolver assemblyResolver, DecompilerSettings settings) at Microsoft.CodeAnalysis.Editor.CSharp.DecompiledSource.CSharpDecompiledSourceService.PerformDecompilation(Document document, String fullName, Compilation compilation, String assemblyLocation) at Microsoft.CodeAnalysis.Editor.CSharp.DecompiledSource.CSharpDecompiledSourceService.<AddSourceToAsync>d__3.MoveNext() --- End of stack trace from previous location where exception was thrown ---

although it looks like it's already decided to decompile the source at that point, so it's already failed to find the actual source file.

[CyrusNajmabadi]

can't someone at microsoft at least do me the common decency of triaging it?

This has been triaged to the backlog. As i mentioned in teh previous post:

Note: this issue is up for grabs. This means that while it's not a high pri for us (and is this on our backlog), we would likely take a community fix it this was important enough for you that you provided a contribution yourself. Thanks! :-)

[CyrusNajmabadi]

even if i delete that .dll, hitting F11 on a reference to a symbol in that project still opens the same metadata file with the same source .dll listed in the header - even though that .dll file no longer exists.

Metadata-as-source caches teh files i believe. It would likely take some extra work to make it support the 'user went and deleted the dll' issue that you're reporting. If you want to open another issue for that it will help track it. Thanks!

[Spongman]

Note: this issue is up for grabs. This means that while it's not a high pri for us (and is this on our backlog), we would likely take a community fix it this was important enough for you that you provided a contribution yourself. Thanks! :-)

thanks. i can read.

[Spongman]

i really don't think you're helping.

[CyrusNajmabadi]

it turns out visual studio is crashing:

This is not a crash. This is marked as:

AppInsightsEvent Name = vs/ide/vbcs/nonfatalwatson

and

WatsonEventType = VisualStudioNonFatalErrors2

We report tehse as events when something unexpected happens. It allows us to see how often this is occurring for users to help decide if it's worth fixing. Thanks :)

[CyrusNajmabadi]

i really don't think you're helping.

You asked if it could be triaged. I'm pointing out this has been triaged. :)

It is currently on the backlog as 'help wanted'. i.e. the triaging determined that this isn't high pri enough to schedule into a current or upcoming sprint. However, if this is important enough for a community member to address, we would take a PR here. Thanks! :)

[Spongman]

please. telling someone who's submitted a big to go fix it themselves is pretty rude. is this how Microsoft is treating their customers now?

[CyrusNajmabadi]

I didn't say you should go fix it yourself. I explained how this has been triaged. Which is that it's currently on our backlog, but that we would welcome a community contribution if someone external is interested in fixing. This is how we triage lots of issues that don't rise to the level of being assigned a particular release.

I'd rather be up front and clear about our triage process and waht these labels mean to help people reading this issue navigate and understand things :)

Note: we have a pretty active and enjoyable community of contributers. For this issue I'd def be happy to try to help you out with a potential fix if you were interested. The places to go where we can chat more on this are gitter.im/dotnet/roslyn and discord.gg/csharp (#roslyn channel). Maybe we can bang something out together pretty quickly on this :)

LMK if interested and i can try to open some time to help out! Thanks! :)