dotnet
Mono Samples should use standard shipping tooling to publish apps
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).
- [X] .NET Core
- [ ] .NET Framework
- [ ] .NET Standard
cc: @elinor-fung @rolfbjarne @lewing @steveisok @kotlarmilos @jonpryor
I thought the purpose of these samples was to show how to use Mono without the iOS/Android SDKs on these platforms?
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?
@steveisok do you have any guidance on this? Are the mobile/wasm tasks from dotnet/runtime officially supported? Should these samples be using them?
@steveisok do you have any guidance on this? Are the mobile/wasm tasks from dotnet/runtime officially supported? Should these samples be using them?
The wasm one could be adapted to use the wasm sdk that is officially supported. I think the mobile ones no longer have any value.
/cc @lewing @vitek-karas
I think the only officially supported way is to use the mobile SDKs. If the only purpose of having the code in the repo is to "document" how to do that without the mobile SDKs then I would vote for use to remove it.
That said, we do have several apps in the runtime repo which are targeting mobile without the use of mobile SDKs - these are for testing purposes. Eventually we could convert those to use mobile SDKs but currently there's value in having them separate. All of the CoreCLR onboarding was first done in the runtime repo and we could enable basic testing via these apps, without the need of having the full mobile SDK support.
