Mono Samples should use standard shipping tooling to publish apps

[jkoritzinsky]

Issue description

Today, the samples under core/mono-samples/ use custom targets with the AppleAppBuilder, AndroidAppBuilder, and WasmAppBuilder tasks from dotnet/runtime to publish apps. None of these tasks are used in production scenarios when targeting netX.0-ios, netX.0-tvos, netX.0-android, netX.0-browser or netX.0-wasi. In fact, these are the only usages of these tasks outside of the dotnet/runtime repository.

Additionally, none of these sample apps target a TFM with the platform, they all target a OSless net6.0 TFM.

Both of these cases describe scenarios that we do not guide our customers to use. All other documentation directs users to use the standard tooling that comes with the OS-suffixed TFM. We should update these samples to use said TFMs and use the standard tooling.

Target framework

Check the .NET target framework(s) being used, and include the version number(s).

• .NET Core
• .NET Framework
• .NET Standard

cc: @elinor-fung @rolfbjarne @lewing @steveisok @kotlarmilos @jonpryor

[rolfbjarne]

I thought the purpose of these samples was to show how to use Mono without the iOS/Android SDKs on these platforms?

[jkoritzinsky]

Is that an officially supported scenario? For example, if someone were to try to file a DTS issue for a problem with AppleAppBuilder, would we cover that under our support policy? Or is the only officially supported way to use .NET on iOS through the netX.0-ios TFM?

Alternatively, would it be more interesting to show a more complete toolchain in the sample instead of pulling "internal" runtime tooling into our external samples repository?

[rolfbjarne]

Is that an officially supported scenario?

I have no idea. @steveisok?