Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avalonia 11.0 has bizarre reference assemblies, malformed Embedded PDB's which break source navigation in Visual Studio. #12431

Closed
chuckries opened this issue Aug 3, 2023 · 4 comments
Labels

Comments

@chuckries
Copy link

Describe the bug
Following up in this repo on behalf of this Visual Studio issue.

The symptom is that F12 Go To Definition is not working for Source Link or embedded files, while it did in the 0.10.21 release. It appears that the 11.0 release started shipping reference assemblies in the NuGet packages. The reference assemblies claim to have embedded PDB's, but the embedded PDB is malformed.

Here is a screenshot from ILSpy. The 11.0.2 net6.0 ref assembly for Avalonia.Controls claims to have an embedded pdb, but the embedded pdb contains no metadata (or the metadata is malformed).
image

The implementation assembly in the lib folder does not have an embedded PDB at all.

I'm not sure what the intent is, but something seems off about these. And, as mentioned, the malformed embedded PDB is breaking source navigation in Visual Studio.

To Reproduce
Steps to reproduce the behavior:

  1. In VS 2022, make a new C# Console App targeting net6.0 or above.
  2. Add a PackageReference to Avalonia 11.0.2
  <ItemGroup>
    <PackageReference Include="Avalonia" Version="11.0.2" />
  </ItemGroup>

  1. Add a code reference to Avalonia.Controls.Templates.IDataTemplate
Avalonia.Controls.Templates.IDataTemplate foo = null;
  1. Place caret on IDataTemplate
  2. F12

Expected behavior
IDataTemplate.cs is opened either from SourceLink or a decopmiled file.

##Actual behavior**
Nothing happens.

If I change my package reference to version 0.10.21, and try the repro again, it obtains the file correctly from Source Link

Additional context
Add any other context about the problem here.

@IanRawley
Copy link
Contributor

I think this is a known issue and fixed in a recently merged PR. #12410 (comment)

@timunie
Copy link
Contributor

timunie commented Aug 4, 2023

@chuckries can you try using latest nightly? If the issue is solved there for you, please close this ticket.

@Mrxx99
Copy link
Contributor

Mrxx99 commented Aug 11, 2023

This seems to be fixed with 11.0.3 (works for me)

@timunie
Copy link
Contributor

timunie commented Aug 11, 2023

closing this due to positive feedback

@timunie timunie closed this as completed Aug 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants