dotnet
[NETSDKE2E][VMR][Regression][VScode][macOS and Win arm64] ASP.Net symbols are missing for IL symbols for non-x64 shared frameworks
Build info
- On Mac and win-arm64
- Install VScode version 1.99.3
- Install C# extension v2.74.24 (latest pre-release from the marketplace)
- NET 10 VMR SDK: 10.0.100-preview.4.25225.104(runtime-10.0.100-preview.4.25225.104)
To Reproduce
-
Create a new ASP.NET Razor project by doing mkdir razor cd razor dotnet new razor
-
Open project in VScode Add the following lines after the “name” line of the “Configurations” object on launch.json file. "justMyCode": false, "symbolOptions": { "searchMicrosoftSymbolServer": true }, "suppressJITOptimizations": true,
Add this line of code on Program.cs file Console.WriteLine("x " + 3);
-
Put breakpoint on this line
- F5 to continue debugging. The breakpoint you added above will get hit. Now F11.You may see the the source code for if (!app.Environment.IsDevelopment()).
Expected Result
This tests ASP.Net symbols at this point it should show you the source code for if (!app.Environment.IsDevelopment())
Actual Result
But it displays as below ASP.Net symbols missing
Note
This issue not repro on Windows-x64
Dotnet --info
.NET SDK: Version: 10.0.100-preview.4.25225.104 Commit: 1164eb4ffb Workload version: 10.0.100-manifests.f1208abc MSBuild version: 17.15.0-preview-25225-104+1164eb4ff
Runtime Environment: OS Name: Mac OS X OS Version: 15.4 OS Platform: Darwin RID: osx-x64 Base Path: /usr/local/share/dotnet/sdk/10.0.100-preview.4.25225.104/
.NET workloads installed: There are no installed workloads to display. Configured to use workload sets when installing new manifests. Workloads are configured to install and update using workload versions, but none were found. Run "dotnet workload restore" to install a workload version.
Host: Version: 10.0.0-preview.4.25225.104 Architecture: x64 Commit: 1164eb4ffb
.NET SDKs installed: 10.0.100-preview.4.25225.104 [/usr/local/share/dotnet/sdk]
.NET runtimes installed: Microsoft.AspNetCore.App 10.0.0-preview.4.25225.104 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 10.0.0-preview.4.25225.104 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Other architectures found: None
Environment variables: Not set
global.json file: Not found
Learn more: https://aka.ms/dotnet/info
Download .NET: https://aka.ms/dotnet/download
Repro on new VMR build 10.0.100-preview.4.25228.107(runtime-10.0.100-preview.4.25228.107)
Still repro on 10.0.100-preview.4.25252.106(runtime-10.0.100-preview.4.25252.106)
@marcpopMSFT I was going through this issue and it looks like it's limited to ARM64. Do we need to fix this for .NET 10 P4?
Probably not a blocker but I will look at this tomorrow. /cc @dotnet/product-construction
@mmitche any updates on this one? This showed up when we are looking at blocking issues for .NET 10 P5 on the validation side.
@balachir @YingyingYuan9 I don't have an arm64 machine handy, but I tried x86 instead and got the expected behavior in Visual Studio. I'm attempting to verify that I can manually download the arm64 symbols now.
After looking into this a bit with @hoyosjs we think we know what is going on. Looks to be an infra issue:
There are N+1 copies of Microsoft.Extensions.Hosting.Abstractions.dll floating around in the product:
- 1 in the Microsoft.Extensions.Hosting package that goes to nuget.org
- N in the aspnetcore shared framework packs/layouts.
Because of trimming (or just separate vertical builds, the versions in the shared framework packs or layouts, which are redisted from the Microsoft.Extensions.Hosting build, do not have the same symbol key as the OOB package. This is fine though, as both sets of PDBs should get published to symbol servers. 1 should come from Microsoft.Extensions.Hosting's symbol package, and N should come from the shared framework symbol packages.
However, the shared framework symbol package is missing some set of pdbs that should be in there:
This could be the result of the move to the new shared framework SDK.
@mmitche @balachir This issue not repro on Windows-arm64 now, just repro on Mac 10.0.100-preview.5.25278.102(runtime-10.0.100-preview.5.25278.102) from sdk/documentation/package-table.md at main · dotnet/sdk
Windows-arm64
Mac
@wtgodbe our validation team reported above that this issue still reproduces for macOS. Do we need an additional fix here for macOS?
I just looked more into this, and from what I can tell, none of the .pdb's have ever been present for the Microsoft.Extensions.* Libraries that we redist from dotnet/runtime - only the .ni.pdb files are present - this is true for every RID, and was also true in 9.0. e.g. this is the 9.0 win-x64 symbol package:
Microsoft.Extensions.Identity.Core & Microsoft.Extensions.Identity.Stores have .pdb's because they're built out of dotnet/aspnetcore, whereas the other Microsoft.Extensions.* libraries are built out of runtime.
Did something w/ the move to the VMR change to where we now need to include these symbols in the aspnetcore SharedFx symbol package? If so, I think the only way to wire it up would be to restore symbol packages from the runtime part of the build, which feels iffy - I don't think there's a regular runtime .nupkg that has these symbols, so we wouldn't have had a good way to do it prior to the VMR, which makes me think it may be wrong to think of this as a requirement
Symbol validation should catch missing symbols with https://dev.azure.com/dnceng/internal/_git/dotnet-release/pullrequest/50676
This issue also reproes on Linux 10.0.100-preview.6.25310.107(runtime-10.0.0-preview.6.25310.107)
@mmitche @wtgodbe I'm trying to understand the status of this issue. It sounds like the ASP.NET symbols are fixed now for Win arm64 but are still missing for macOS and linux. Do you want us to open a separate issue to track the macOS and Linux case? Or is this issue still the right one to track that?
Nope, you can leave this issue open, covering all cases. @wtgodbe Can you post an update on the fix when you get a chance?
