Support for `$(TargetFrameworks)` per `$(RuntimeIdentifier)` (RID)

jonathanpeppers commented 8 months ago

Is your feature request related to a problem? Please describe.

Currently, Android projects build 4 architectures by default:

<TargetFramework>net9.0-android<TargetFramework>
<!-- these are implicit if you leave them blank -->
<RuntimeIdentifiers>android-arm;android-arm64;android-x86;android-x64</RuntimeIdentifiers>

We have custom MSBuild logic that "combines" the 4 architectures and emits a final Android package at the end. To make this work, we run an <MSBuild /> task per-RID that runs a subset of the dotnet publish MSBuild targets for trimming, Mono AOT compilation, etc.

It would be nice if the .NET SDK had built-in support for this, as it could be useful for several scenarios:

Android (as mentioned)
macOS or MacCatalyst, has similar logic as Android. Mac apps on the App Store should target x64 and arm64 currently.
I have a console app, I want to publish it with NativeAOT, single file, targeting N platforms.

Describe the solution you'd like

One solution, would be to make a new TargetFramework syntax, such as:

<TargetFrameworks>net9.0-android/android-arm;net9.0-android/android-arm64;net9.0-android/android-x86;net9.0-android/android-x64</TargetFrameworks>

The .NET SDK would handle running inner/outer builds with the <MSBuild/> task.

PROs

This would enable the Android & macOS/MacCatalyst workloads to rely on logic in the .NET SDK instead of inventing our own.

This also would be useful, in that new #if directives could exist like:

#if ARM || ARM64
    // Do some "arm"-y stuff
#elif X86 || X64
    // Do some macOS Intel or Android emu/Chromebook/WSA stuff
#endif

This would be useful on both macOS and Android.

CONs

We now run the C# compiler N times. Build performance concerns?
MAUI projects will have a combinatorial explosion of $(TargetFrameworks).

Additional context

This is related to:

marcpopMSFT commented 8 months ago

Nuget is looking into TFM aliasing that could potentially enable this. They are looking at allowing multiple identical underlying target frameworks in a single project which is what is needed for this. Then there would likely need SDK work to enable using aliases with rids.

CC @zivkan for visibility on an alias use case.

dsplaisted commented 8 months ago

Here is the issue tracking the NuGet work which would be the next step towards enabling this: https://github.com/NuGet/Home/pull/12124

jonathanpeppers commented 8 months ago

The part that seems tricky about this feature, do we really want a MAUI project to look like:

<TargetFrameworks>
  net9.0-android/android-arm;
  net9.0-android/android-arm64;
  net9.0-android/android-x64;
  net9.0-android/android-x86;
  net9.0-ios/iossimulator-arm64;
  net9.0-ios/ios-arm64;
  net9.0-maccatalyst/maccatalyst-arm64;
  net9.0-maccatalyst/maccatalyst-x64;
  net9.0-tizen;
  net9.0-windows10.0.19041.0;
</TargetFrameworks>

The property is so long now, it made me think to put each entry on its own line.

In the case of iOS, you would do debugging/development with the iOS simulator and Release/App Store builds are ios-arm64.

dotnet / sdk