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.

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

Support multi-arch install locations #214

Merged
merged 10 commits into from
May 12, 2021

Conversation

vitek-karas
Copy link
Member

This is a proposal how to update the install location behavior in .NET 6 to support multiple architectures on a single machine across all platforms.

@vitek-karas vitek-karas added this to the 6.0.0 milestone May 3, 2021
@vitek-karas vitek-karas self-assigned this May 3, 2021
@vitek-karas
Copy link
Member Author

/cc @agocke @LakshanF @sbomer @mateoatr

@vitek-karas
Copy link
Member Author

/cc @jkotas

@jkotas
Copy link
Member

jkotas commented May 4, 2021

You may want to cc stakeholders for dotnet test and for installers since this will have an impact on them.

Looks good to me otherwise. I like what you came up with.

@richlander
Copy link
Member

I would like to see a call-out for what happens on macOS when Rosetta 2 gets removed such that x64 emulation is no longer possible and x64 apphost will fail to execute.

There are a few scenarios I want to understand better:

  • .NET 6 x64 is installed, only. What contents does the file have?
  • .NET 6 Arm64 is installed, only. What contents does the file have?
  • .NET 6 x64 and Arm64 are installed, only. What contents does the file have?
  • An updated .NET 5 x64 is install, only. What contents does the file have?

Assume macOS for the answers.

I assume that whatever the answers are that runtime and SDK installers will have the same behavior. Yes?

@vitek-karas
Copy link
Member Author

I would like to see a call-out for what happens on macOS when Rosetta 2 gets removed such that x64 emulation is no longer possible and x64 apphost will fail to execute.

Well you said it yourself - x64 apphost will fail to start - you will get an OS provided error (not sure what that will look like). It really doesn't matter what's installed, we will never get that far.

Answers to your question heavily depend on the capabilities of the installer tech we use. If we can have clever installers then it would be this:

.NET 6 x64 is installed, only. What contents does the file have?

x64=/usr/local/share/dotnet/x64

.NET 6 Arm64 is installed, only. What contents does the file have?

arm64=/usr/local/share/dotnet

.NET 6 x64 and Arm64 are installed, only. What contents does the file have?

arm64=/usr/local/share/dotnet
x64=/usr/local/share/dotnet/x64

An updated .NET 5 x64 is install, only. What contents does the file have?

/usr/local/share/dotnet/x64

(In theory it could also write x64=/usr/local/share/dotnet/x64, but it's not really needed since 5.0 apphost will not recognize that anyway - we would only do that if we needed cooperation between installers).

I assume that whatever the answers are that runtime and SDK installers will have the same behavior. Yes?

SDK installers should not do anything to the registration mechanism (the config file). It's solely about the runtime installers. If you install SDK you also install at least one runtime, which will take care of that part.

I can try to incorporate some of this into the doc if you think it's worth it.

@vitek-karas
Copy link
Member Author

@marcpopMSFT for possible dotnet test impact - ideally test infra would switch to use apphost (just like it does on Windows already) in which case it would get the desired behavior for free - due to the changes proposed here.

@dleeapho for the impact on runtime installers, since those are the once who should be registering the install locations (on all platforms).

@richlander
Copy link
Member

@vitek-karas thanks. That answer is good enough. It gets to what I was wondering about. As you say, it comes down to how smart the installer is.

@vitek-karas
Copy link
Member Author

Forgot to add: If the installer is "dumb" we could go with a simple:
Every installer writes the same content - always:

/usr/local/share/dotnet/x64
arm64=/usr/local/share/dotnet
x64=/usr/local/share/dotnet/x64

If we think it's not worth the trouble to complicate the installers, that's what all of them can do and it won't go wrong (especially since the ones we already shipped don't write that file at all, so there's nothing overwrite).
And then after Rosetta is removed we simplify the installer to only write the arm64 line.

@richlander
Copy link
Member

@vitek-karas Exactly. I assumed that as a consequence of your other statements. Good to call out explicitly.

@agocke
Copy link
Member

agocke commented May 4, 2021

I think we'll still need separate values for installers for x64 on Intel Macs.

@vitek-karas
Copy link
Member Author

I think we'll still need separate values for installers for x64 on Intel Macs.

@agocke I don't understand your question. On x64, .NET 6 installer should write this to the file:

/usr/local/share/dotnet
x64=/usr/local/share/dotnet

(I know it's redundant, but it's better for future to be explicit as much as possible - and also we get consistent behavior across the platforms).

@agocke
Copy link
Member

agocke commented May 4, 2021

@vitek-karas Right, just pointing out

Every installer writes the same content

I think the above is correct but different between the osx-x64 installer and the osx-arm64_x64 installer.

@richlander
Copy link
Member

richlander commented May 6, 2021

FYI: #217 (broader x64 emulation plan)

accepted/2021/install-location-per-architecture.md Outdated Show resolved Hide resolved
accepted/2021/install-location-per-architecture.md Outdated Show resolved Hide resolved
accepted/2021/install-location-per-architecture.md Outdated Show resolved Hide resolved
accepted/2021/install-location-per-architecture.md Outdated Show resolved Hide resolved
@vitek-karas vitek-karas merged commit bbe4490 into dotnet:main May 12, 2021
@vitek-karas vitek-karas deleted the ApphostPerArch branch May 12, 2021 09:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants