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.

Sign up for GitHub

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

Jump to bottom

Packaging & redistribution of mdoc.exe & mono-symbolicate in a .NET 6 world? #35852

Open
jonpryor opened this issue May 5, 2020 · 6 comments
Open

Packaging & redistribution of mdoc.exe & mono-symbolicate in a .NET 6 world? #35852

jonpryor opened this issue May 5, 2020 · 6 comments
Labels
area-Meta question Answer questions and provide assistance, not an issue with source code or documentation.
Milestone
Future

Comments

@jonpryor
Copy link
Member

jonpryor commented May 5, 2020

In Xamarin.Android 10.5 and previous releases, Xamarin.Android redistributes mdoc.exe and mono-symbolicate.exe -- along with other assemblies -- which come from a "mono archive."

These utilities are used from various targets, e.g. from the BuildDocumentation target in Xamarin.Android.Bindings.targets or the SignAndroidPackage target in Xamarin.Android.Common.targets.

In a .NET 5 world, where should these utilities reside? Should they continue to be distributed as part of Xamarin.Andrdoid/Microsoft.Android? Should they be part of dotnet itself? Some other NuGet package?
@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added area-Meta untriaged New issue has not been triaged by the area owner labels May 5, 2020
@jonpryor
Copy link
Member Author

jonpryor commented May 5, 2020

@steveisok: Thoughts?

@jonathanpeppers
Copy link
Member

A few more of these:

  • aprofutil.exe
  • cil-strip.exe
  • illinkanalyzer.exe
  • mkbundle.exe
  • mono-api-html.exe
  • mono-api-info.exe

I don't know how many of these will be relevant going forward, though.

@steveisok
Copy link
Member

Good question. It's something I'll bring up in our next stand up.

@jonpryor
Copy link
Member Author

jonpryor commented May 5, 2020

mono-api-html and mono-api-info were previously used for xamarin-android's API compatibility checks. They should no longer be necessary.

We've agreed that we can drop mkbundle support for .NET 5, at least momentarily, so that's not a concern.

cil-strip.exe will likely be "folded" into the dotnet build/dotnet publish infrastructure, as part of AOT/etc. It may not need to be used directly from Xamarin.Android.

aprofutil.exe and illinkanalyzer.exe are intended for "end-developer use", to view profiler output and analyze linker behavior. They don't need to be part of Xamarin.Android per-se, but they need to be present somewhere. Perhaps they should become dotnet tools?

@jonpryor jonpryor mentioned this issue May 5, 2020
Closed
@marek-safar marek-safar added the question Answer questions and provide assistance, not an issue with source code or documentation. label May 6, 2020
@CoffeeFlux CoffeeFlux removed the untriaged New issue has not been triaged by the area owner label Jul 6, 2020
@joperezr joperezr added this to the Future milestone Jul 7, 2020
jonpryor pushed a commit to dotnet/android that referenced this issue Aug 7, 2020
@jonathanpeppers
[build] enable more One .NET MSBuild tests (#4820)
3c4c8de 
*Invert* the MSBuild unit tests & One .NET Relationship: previously,
we would selectively *enable* our MSBuild tests to run under .NET 5+.
Now, run *all* tests under .NET 5+, *except* for the categories:

  * `AOT` and `MonoSymbolicate`: requires Mono AOT support in .NET 5
    and packaging of required tooling; see also, but not limited to,
    <dotnet/runtime#35852>
    <dotnet/runtime#36758>

  * `FSharp`: [Xamarin.Android.FSharp.ResourceProvider][0] support
    is needed to run on .NET 5.

  * `LibraryProjectZip`, `StaticProject`: Require future support
    within Xamarin.Android, but don't need to be done *before*
    inverting the unit test regime.

  * `MkBundle`: `mkbundle.exe` might not make it to .NET 5 -- see
    also dotnet/runtime#35852 -- and it may be moot with d236af5.

  * `PackagesConfig`: .NET 5+ won't support `packages.config` files.

Also rework our build pipeline to run the MSBuild tests across 12
CI machines:

  * Windows - Node 1 - Legacy
  * Windows - Node 2 - Legacy
  * Windows - Node 3 - Legacy
  * Windows - Node 1 - One .NET
  * Windows - Node 2 - One .NET
  * Windows - Node 3 - One .NET
  * macOS - Node 1 - Legacy
  * macOS - Node 2 - Legacy
  * macOS - Node 3 - Legacy
  * macOS - Node 1 - One .NET
  * macOS - Node 2 - One .NET
  * macOS - Node 3 - One .NET

Since this is a lot of machines:

 1. I moved all the `One .NET` tests to their own phase.
 2. The phase only runs when `RunAllTests=true`.  This means the
    `One .NET` tests will run on master, release branches, and
    Mono bumps.

    You can manually queue a build to enable `RunAllTests` on a PR.

To be completed in another PR, there are still more test assemblies
that need to be run under a `dotnet` context:

  * `Xamarin.Android.Build.Tests.Commercial.dll`
  * `MSBuildDeviceIntegration.dll`

[0]: https://github.com/xamarin/Xamarin.Android.FSharp.ResourceProvider
@CoffeeFlux
Copy link
Contributor

While not pressing, netcore mkbundle support might be nice at some point just for the purpose of trying to reproduce Blazor-related issues outside of the browser and to generally be more confident in our single-file functionality. cc: @lambdageek

@marek-safar
Copy link
Contributor

There is already single-file like support in .NET 3.1 and .NET 5.0. Maybe it can be redesign for the 3rd time to support all .NET scenarios in .NET 6.0

/cc @agocke

@bruno-garcia bruno-garcia mentioned this issue Jan 4, 2021
Open
@Redth Redth changed the title Packaging & redistribution of mdoc.exe & mono-symbolicate in a .NET 5 world? Packaging & redistribution of mdoc.exe & mono-symbolicate in a .NET 6 world? Apr 19, 2021
@ghost ghost added the needs-further-triage Issue has been initially triaged, but needs deeper consideration or reconsideration label Apr 19, 2021
@spouliot spouliot mentioned this issue Apr 20, 2021
Open
6 tasks
@joperezr joperezr removed the needs-further-triage Issue has been initially triaged, but needs deeper consideration or reconsideration label Apr 29, 2021
@jonathanpeppers jonathanpeppers mentioned this issue May 1, 2023
Open
@jonathanpeppers jonathanpeppers mentioned this issue Mar 26, 2024
Open
@tommcdon tommcdon mentioned this issue Jun 11, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area-Meta question Answer questions and provide assistance, not an issue with source code or documentation.
Projects
No open projects
Triage POD for Reflection, META, etc.
Status: Future
Milestone
Future
Development

No branches or pull requests
7 participants
@jonpryor @marek-safar @steveisok @jonathanpeppers @CoffeeFlux @joperezr @Dotnet-GitSync-Bot