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

[jonpryor]

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?

[jonpryor]

@steveisok: Thoughts?

[jonathanpeppers]

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]

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

[jonpryor]

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?

[CoffeeFlux]

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]

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