[build] Use SharedFramework.Sdk to create workload packs #10000

pjcollins · 2025-04-02T18:49:36Z

Our workload packaging logic has been updated to use more of the
Microsoft.DotNet.SharedFramework.Sdk MSBuild SDK included in the
dotnet/arcade repo.

This SDK allows us to easily exclude the symbols files that we've been
shipping directly in all of our workload packs, and instead move them
into *.symbols.nupkg packages that can be archived and uploaded to
a symbol server separately.

Our workload packaging logic has been updated to use more of the [Microsoft.DotNet.SharedFramework.Sdk][0] MSBuild SDK included in the dotnet/arcade repo. This SDK allows us to easily exclude the symbols files that we've been shipping directly in all of our workload packs, and instead move them into `*.symbols.nupkg`` packages that can be archived and uploaded to a symbol server separately. [0]: https://github.com/dotnet/arcade/tree/21f46f494265f11e124c47ee868fac199768a35b/src/Microsoft.DotNet.SharedFramework.Sdk

pjcollins · 2025-04-02T18:55:31Z

tests/MSBuildDeviceIntegration/Tests/DebuggingTest.cs

@@ -425,8 +425,6 @@ public Foo ()
 						$"{app.ProjectName}.pdb should be deployed!");
 					StringAssertEx.ContainsRegex ($@"NotifySync CopyFile.+{lib.ProjectName}\.pdb", appBuilder.LastBuildOutput,
 						$"{lib.ProjectName}.pdb should be deployed!");
-					StringAssertEx.ContainsRegex ($@"NotifySync CopyFile.+Mono.Android\.pdb", appBuilder.LastBuildOutput,
-						$"Mono.Android.pdb should be deployed!");


@dellis1972 @jonathanpeppers With the changes in this PR to remove symbols from runtime packs, I've had to update a few tests that check for the existance of Mono.Android.pdb in the apk/fastdev location after install. This didn't seem to cause any issues in our other tests, but I'm wondering if this will have some impact on the debugging experience? We'll still be pushing these files to various symbol servers, but do they also need to be deployed to a target device/emulator?

I feel like for Mono the .pdb is required to be deployed, is that correct @dellis1972?

For CoreCLR, we don't know yet what the requirements will be.

We probably need to .pdb for Mono.Android if we want to step through the code for Mono.Android.
It would be nice to check if the Debugger tests still work without it.

That said if the pdb is present we will get better stack traces if there are crashes inside Mono.Android which would make for a better debugging experience.

I've never been clear on the the symbols servers really work for those on Mac/Linux. I know VS can fetch them, but Ive never seem VSCode do anything like that.

Ok, so the only thing we might have to test:

Setup a Android.Widget.Button click event, our template probably has one

put throw new Exception(); inside

See if Visual Studio / VS Code can break (pause) on the line of the exception

I suspect this might not work without the Mono.Android.pdb? @jonpryor do you have a memory of that?

I spent some time testing this today in a couple of different dev boxes. As far as I can tell, the only noticeable difference is related to stack traces and line number/information for code within Mono.Android.dll. For example:

.NET 10 preview 2:

[AndroidRuntime] android.runtime.JavaProxyThrowable: [System.Exception]: Goodbye button [AndroidRuntime] at AndroidApp10p2TestSym.MainActivity+<>c__DisplayClass1_0.<OnCreate>b__0(C:\Users\pecolli\source\AndroidApp10p2TestSym\MainActivity.cs:19) [AndroidRuntime] at Android.Views.View+IOnClickListenerImplementor.OnClick(/Users/runner/work/1/s/xamarin-android/src/Mono.Android/obj/Release/net10.0/android-35/mcw/Android.Views.View.cs:2520) [AndroidRuntime] at Android.Views.View+IOnClickListenerInvoker.n_OnClick_Landroid_view_View_(/Users/runner/work/1/s/xamarin-android/src/Mono.Android/obj/Release/net10.0/android-35/mcw/Android.Views.View.cs:2477) [AndroidRuntime] at mono.android.view.View_OnClickListenerImplementor.n_onClick(Native Method) [AndroidRuntime] at mono.android.view.View_OnClickListenerImplementor.onClick(View_OnClickListenerImplementor.java:29) [AndroidRuntime] at android.view.View.performClick(View.java:8028) [AndroidRuntime] at android.view.View.performClickInternal(View.java:8005)

This PR:

[AndroidRuntime] android.runtime.JavaProxyThrowable: [System.Exception]: Goodbye button [AndroidRuntime] at AndroidApp10TestSym.MainActivity+<>c__DisplayClass1_0.<OnCreate>b__0(C:\Users\pecolli\source\AndroidApp10TestSym\MainActivity.cs:20) [AndroidRuntime] at Android.Views.View+IOnClickListenerImplementor.OnClick + 0xa(Unknown Source) [AndroidRuntime] at Android.Views.View+IOnClickListenerInvoker.n_OnClick_Landroid_view_View_ + 0xe(Unknown Source) [AndroidRuntime] at mono.android.view.View_OnClickListenerImplementor.n_onClick(Native Method) [AndroidRuntime] at mono.android.view.View_OnClickListenerImplementor.onClick(View_OnClickListenerImplementor.java:29) [AndroidRuntime] at android.view.View.performClick(View.java:8028) [AndroidRuntime] at android.view.View.performClickInternal(View.java:8005)

I also couldn't manage to get VS to load Mono.Android.pdb from a local file path while debugging, and I'm not sure if we'll be able resolve from a symbol server either or if the .pdb file needs to be deployed to the target device/emu to get this information. That being said, I'm not sure how useful these paths/line numbers for generated code are? We also don't deploy any symbols from any other BCL assemblies.

Aside from this, all of our automated debugger tests are still passing against this PR on both Windows and macOS.

Spent some more time trying to step into the base activity OnCreate method and was unable to do so with both .NET 9 and .NET 10 preview 2. I think we're reasonably confident we won't be regressing the debugging experience by removing Mono.Android.pdb at this time so I'll take this out of draft for further review.

@dellis1972 wrote:

We probably need to .pdb for Mono.Android if we want to step through the code for Mono.Android.

The problem is that there is very little code within Mono.Android.dll which can be stepped through. If the code is generated, we cannot step into it. @pjcollins confirmed this recently with .NET 9: set a breakpoint on base.OnCreate(bundle), and while you can "step into" it, you won't see any source code for it.

For example, from 7b4d4b8:

% $HOME/.dotnet/tools/sourcelink print-urls src/Mono.Android/obj/Debug/net10.0/android-36/Mono.Android.pdb bd429029b775f558c3ca50e4735d64decd034427991fe9ba9be5cf31e2588455 sha256 csharp …/src/dotnet/android/src/Mono.Android/obj/Debug/net10.0/android-36/mcw/Android.App.Activity.cs embedded …

which yes says "embedded", but afaict nothing is able to view that embedded data?

pjcollins · 2025-04-07T16:42:59Z

Testing with an official build here, I'll need to run this through the symbol archiving and VS insertion process to make sure we are still processing and retaining symbols from the new symbols.nupkg artifacts correctly - https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=11352883&view=results

pjcollins · 2025-04-08T14:38:26Z

No Android related symbols issues were reported in this PR https://devdiv.visualstudio.com/DevDiv/_git/VS/pullrequest/626310, I believe this should be good to go from an official build perspective as well

Conflicts: build-tools/automation/yaml-templates/build-linux.yaml

jonpryor · 2025-04-08T19:35:22Z

Context: https://github.com/dotnet/arcade/blob/2b1931c05dd6ceb89120131a8b39eaa81735179a/src/Microsoft.DotNet.SharedFramework.Sdk/targets/sharedfx.targets#L398-L429

(_GenerateFrameworkList target)

pjcollins commented Apr 2, 2025

View reviewed changes

Merge remote-tracking branch 'origin/main' into dev/pjc/sfxpack

6e4681c

pjcollins marked this pull request as ready for review April 7, 2025 15:41

pjcollins requested a review from jonpryor as a code owner April 7, 2025 15:41

Add symbols.nupkg to vs drops

791a491

Merge remote-tracking branch 'origin/main' into dev/pjc/sfxpack

f8e7cec

Conflicts: build-tools/automation/yaml-templates/build-linux.yaml

jonpryor merged commit dc08972 into main Apr 8, 2025
57 of 59 checks passed

jonpryor deleted the dev/pjc/sfxpack branch April 8, 2025 19:44

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[build] Use SharedFramework.Sdk to create workload packs #10000

[build] Use SharedFramework.Sdk to create workload packs #10000

pjcollins commented Apr 2, 2025 •

edited

Loading

pjcollins Apr 2, 2025

jonathanpeppers Apr 2, 2025

dellis1972 Apr 3, 2025

jonathanpeppers Apr 3, 2025 •

edited

Loading

pjcollins Apr 3, 2025

pjcollins Apr 7, 2025

jonpryor Apr 7, 2025 •

edited

Loading

pjcollins commented Apr 7, 2025 •

edited

Loading

pjcollins commented Apr 8, 2025

jonpryor commented Apr 8, 2025

[build] Use SharedFramework.Sdk to create workload packs #10000

[build] Use SharedFramework.Sdk to create workload packs #10000

Conversation

pjcollins commented Apr 2, 2025 • edited Loading

pjcollins Apr 2, 2025

Choose a reason for hiding this comment

jonathanpeppers Apr 2, 2025

Choose a reason for hiding this comment

dellis1972 Apr 3, 2025

Choose a reason for hiding this comment

jonathanpeppers Apr 3, 2025 • edited Loading

Choose a reason for hiding this comment

pjcollins Apr 3, 2025

Choose a reason for hiding this comment

pjcollins Apr 7, 2025

Choose a reason for hiding this comment

jonpryor Apr 7, 2025 • edited Loading

Choose a reason for hiding this comment

pjcollins commented Apr 7, 2025 • edited Loading

pjcollins commented Apr 8, 2025

jonpryor commented Apr 8, 2025

pjcollins commented Apr 2, 2025 •

edited

Loading

jonathanpeppers Apr 3, 2025 •

edited

Loading

jonpryor Apr 7, 2025 •

edited

Loading

pjcollins commented Apr 7, 2025 •

edited

Loading