[bundle] Include mono's debug symbols #513
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Microsoft has (several?) [symbol servers][0], which is a repository "somewhere" which contains debug symbols, so that when a stack trace containing e.g. BCL stack frames is sent to Microsoft, there is a way to correlate that back to filename and line number source for further investigation. Xamarin.Android has not partaken in this mechanism, in large part because we did most of our building on Linux and macOS machines which generate `.mdb` debug symbols, while symbol servers require `.pdb`. That constraint is now behind us; with 76be1fb and the use of Mono 4.9 for builds, our builds now generate Portable `.pdb` files, which *should* (hopefully) be usable on Microsoft's symbol servers. However, to transmit them to Microsoft's servers, we need to actually *retain* them. At present, they're not: because of `bundle*.zip` use, the `mscorlib.dll` that we include in the final product may have been built much earlier than the rest of the product, and we don't have any other mechanism to retain the `mscorlib.pdb` file. Let's change that: update `mono-runtimes.targets` so that the created debug symbol files are included in the produced `bundle*.zip`, and bump the corresponding `$(XABundleFileName)` version number. This will ensure that we retain the debug symbols for our BCL assemblies, allowing us to actually have something to upload. [0]: https://msdn.microsoft.com/en-us/library/cc667410.aspx
dellis1972
approved these changes
Mar 22, 2017
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Nov 19, 2019
Changes: dotnet/java-interop@baf43b0...166a6c9 Fixes: dotnet/java-interop#519 * dotnet/java-interop@166a6c9: [Java.Interop-Tests] Remove Reflection from JavaPrimitiveArrayContract (dotnet#521) * dotnet/java-interop@09083d9: [generator] Support empty package names (dotnet#520) * dotnet/java-interop@af3dc77: [build] Set up YAML Azure pipeline. (dotnet#516) * dotnet/java-interop@8602581: [java-interop] Enabling -fPIC on Linux build - part 2 (dotnet#518) * dotnet/java-interop@ff3081d: [build] Migrate library projects to SDK style + netstandard2.0 (dotnet#507) * dotnet/java-interop@f5d29c3: [generator] Ensure all usage of parameter names are escaped the same (dotnet#506) * dotnet/java-interop@17cdf54: Add vscode files so we can build/debug/test from inside the vscode ide (dotnet#513)
jonpryor
added a commit
that referenced
this pull request
Nov 20, 2019
Changes: dotnet/java-interop@baf43b0...166a6c9 Fixes: dotnet/java-interop#519 * dotnet/java-interop@166a6c9: [Java.Interop-Tests] Remove Reflection from JavaPrimitiveArrayContract (#521) * dotnet/java-interop@09083d9: [generator] Support empty package names (#520) * dotnet/java-interop@af3dc77: [build] Set up YAML Azure pipeline. (#516) * dotnet/java-interop@8602581: [java-interop] Enabling -fPIC on Linux build - part 2 (#518) * dotnet/java-interop@ff3081d: [build] Migrate library projects to SDK style + netstandard2.0 (#507) * dotnet/java-interop@f5d29c3: [generator] Ensure all usage of parameter names are escaped the same (#506) * dotnet/java-interop@17cdf54: Add vscode files so we can build/debug/test from inside the vscode ide (#513)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Microsoft has (several?) symbol servers, which is a repository
"somewhere" which contains debug symbols, so that when a stack trace
containing e.g. BCL stack frames is sent to Microsoft, there is a way
to correlate that back to filename and line number source for further
investigation.
Xamarin.Android has not partaken in this mechanism, in large part
because we did most of our building on Linux and macOS machines which
generate
.mdbdebug symbols, while symbol servers require.pdb.That constraint is now behind us; with 76be1fb and the use of
Mono 4.9 for builds, our builds now generate Portable
.pdbfiles,which should (hopefully) be usable on Microsoft's symbol servers.
However, to transmit them to Microsoft's servers, we need to actually
retain them. At present, they're not: because of
bundle*.zipuse,the
mscorlib.dllthat we include in the final product may have beenbuilt much earlier than the rest of the product, and we don't have any
other mechanism to retain the
mscorlib.pdbfile.Let's change that: update
mono-runtimes.targetsso that the createddebug symbol files are included in the produced
bundle*.zip, andbump the corresponding
$(XABundleFileName)version number. This willensure that we retain the debug symbols for our BCL assemblies,
allowing us to actually have something to upload.