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

Default RuntimeIdentifier #10861

Closed
rolfbjarne opened this issue Mar 12, 2021 · 2 comments · Fixed by #11983
Closed

Default RuntimeIdentifier #10861

rolfbjarne opened this issue Mar 12, 2021 · 2 comments · Fixed by #11983
Assignees
@rolfbjarne
Labels
dotnet An issue or pull request related to .NET (6) dotnet-pri0 .NET 6: required for stable release request-for-comments The issue is a suggested idea seeking feedback
Milestone
.NET 6

Comments

@rolfbjarne
Copy link
Member

rolfbjarne commented Mar 12, 2021 •
edited
Loading

Currently we require the RuntimeIdentifier to be set in order to build on all the Apple platforms, but having a default RuntimeIdentifier might make sense, at least in certain cases (and we don't have to do the same thing on all platforms).

Desktop platforms (macOS + Mac Catalyst)

For desktop platforms (macOS + Mac Catalyst), we have the choice between x64 and arm64, and at least for these platforms I think we should set a default. Options:

  1. Require the developer to specify (what we do now).
  2. Set the default to x64. Most compatible (runs on both arm64 and x64).
  3. Set the default to arm64. Most future-proof (probably), but will be non-intuitive when building on an x64 machine (since the app won't launch).
  4. Set the default to the CPU of the machine. Probably the best user experience, but it's undeterministic, since the results depend on the machine you're using to build (CI can become frustrating).

IMHO the second option is the one that makes the most sense.

At least for now I think it makes most sense to have the same default for both platforms.

Mobile platforms (iOS + tvOS)

We have more options here, because the app can target either a simulator or a device - this is really what it comes down to, if we should default to simulator or device, or if we should require the user to specify.

  1. Require the developer to specify (what we do now).
  2. Default to build for simulator.
    Pro: should always be able to build something that can be launched.
    Con: ?
  3. Default to build for device.
  4. Detect if there are any devices attached, and if so build for device, if not build for the simulator
    Cons: undeterministic. Someone trips over a network cable that disconnects your Apple TV, and suddenly your build behaves differently?
  5. Build for both the simulator and device just in case.
    Cons: Slow. Will always spend time building something that is not needed.

IMHO we should default to the simulator (if we decide to default to anything).

We should also have in mind that we might want to change the default later.

Any other options/opinions?

We should also validate that the RuntimeIdentifier is one of the values we support.
@rolfbjarne rolfbjarne added request-for-comments The issue is a suggested idea seeking feedback dotnet An issue or pull request related to .NET (6) labels Mar 12, 2021
@rolfbjarne rolfbjarne added this to the .NET 6 milestone Mar 12, 2021
@jonathanpeppers
Copy link
Member

My thinking for making the iOS simulator default is to make the getting started experience smoother. A first-time user probably won't have a device connected yet, but the simulator would be able to launch fine. An experienced user will more likely understand how to change a setting to deploy to a device.

Hopefully, the IDE would be able to select the right $(RuntimeIdentifier) when you select a device in the dropdown?

@spouliot
Copy link
Contributor

Desktop platforms (macOS + Mac Catalyst)

Agreed with option 2.
We can print something like Building for x86_64 (default). Override with XXX on the console (useful in logs).

Mobile platforms (iOS + tvOS)

Agreed with option 2 on Mac
The (small) con would be to decide "which" simulator (e.g. iPhone vs iPad) but that's more a launch than a build issue (unless they start to differ more in the future)

On Windows... then a Mac might not be connected so it would make sense to build for a device. However it's more an IDE thing than the default tool (which runs on the Mac).

Hopefully, the IDE would be able to select the right $(RuntimeIdentifier) when you select a device in the dropdown?

Yes, my understanding is that is more CLI defaults than IDE, just like we had with mtouch before.

@rolfbjarne rolfbjarne added the dotnet-pri0 .NET 6: required for stable release label Jun 8, 2021
@rolfbjarne rolfbjarne self-assigned this Jun 8, 2021
@rolfbjarne rolfbjarne mentioned this issue Jun 14, 2021
Closed
rolfbjarne added a commit to rolfbjarne/xamarin-macios that referenced this issue Jun 15, 2021
@rolfbjarne
[dotnet] Set a default RuntimeIdentifier and validate that we get a v…
c344f63 
…alid RuntimeIdentifier. Fixes xamarin#10861.

Also add tests:

* Remove RuntimeIdentifier from a few sample projects. These projects should
  continue to build just fine.
* Add tests for invalid RuntimeIdentifiers.

Fixes xamarin#10861.
rolfbjarne added a commit to rolfbjarne/xamarin-macios that referenced this issue Jun 16, 2021
@rolfbjarne
[dotnet] Set a default RuntimeIdentifier and validate that we get a v…
9591743 
…alid RuntimeIdentifier. Fixes xamarin#10861.

Also add tests:

* Remove RuntimeIdentifier from a few sample projects. These projects should
  continue to build just fine.
* Add tests for invalid RuntimeIdentifiers.

Fixes xamarin#10861.
rolfbjarne added a commit to rolfbjarne/xamarin-macios that referenced this issue Jun 18, 2021
@rolfbjarne
[dotnet] Set a default RuntimeIdentifier and validate that we get a v…
724d0fe 
…alid RuntimeIdentifier. Fixes xamarin#10861.

Also add tests:

* Remove RuntimeIdentifier from a few sample projects. These projects should
  continue to build just fine.
* Add tests for invalid RuntimeIdentifiers.

Fixes xamarin#10861.
This was referenced Jun 18, 2021
Closed
Merged
Closed
rolfbjarne added a commit that referenced this issue Jun 29, 2021
@rolfbjarne
[dotnet] Add support for universal apps. (#11983)
ebf6c13 
Add support for universal / fat apps for iOS, macOS and Mac Catalyst.

We detect if we need to build a universal app by checking if `RuntimeIdentifiers` (plural) is set, and in that case we do a complete inner build for every `RuntimeIdentifier`, and then once those inner builds are done, we merge the resulting .app bundles together (using a new MSBuild task called `MergeAppBundles`).

When merging app bundles together, we'll run into files that exist in both apps. Depending on the file type, we do different things:

* MachO flies: lipo'ed together.
* Managed assemblies: we do a binary comparison, if the assemblies are different, we put them in a RID-specific subdirectory. At runtime we know to look for assemblies in this directory.
* runtimeconfig.bin, icudt.dat: put in a RID-specific subdirectory.
* Info.plist: computed in the outer (fat) build, the one from the inner build is ignored.
* Other files: for identical files we just copy one, otherwise we show an error.

If we run into files that are different between apps, but we should handle somehow, then we'll have to decide on a case-to-case basis what to do.

Some code shuffling was required to increase code sharing between the tools/ code, the msbuild/ code, and tests.

I've also added support for a default `RuntimeIdentifier`.

Fixes #10294.
Fixes #10861.
@rolfbjarne rolfbjarne mentioned this issue Jul 27, 2021
Closed
@ghost ghost locked as resolved and limited conversation to collaborators Apr 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@rolfbjarne rolfbjarne

Labels
dotnet An issue or pull request related to .NET (6) dotnet-pri0 .NET 6: required for stable release request-for-comments The issue is a suggested idea seeking feedback
Projects
None yet
Milestone
.NET 6
Development

Successfully merging a pull request may close this issue.

[dotnet] Add support for universal apps. rolfbjarne/xamarin-macios
3 participants
@rolfbjarne @spouliot @jonathanpeppers