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

Create x86 installer for win-arm64 runtime, to allow easy install on win-arm64 machines using x86 emulation #1529

Closed
dagood opened this issue Jan 9, 2020 · 4 comments · Fixed by dotnet/arcade#5688
Assignees
Milestone

Comments

@dagood
Copy link
Member

dagood commented Jan 9, 2020

Idea from @voronoipotato at dotnet/core#3765 (comment)

We aren't realistically able to create an arm64 installer for win-arm64 yet due to lack of support from the installer tech we depend on (https://github.com/dotnet/core-setup/issues/5456) but running an installer under x86 emulation is another option to jump ahead on making .NET Core easier to use on win-arm64 machines.

This issue covers the .NET Core Runtime, but this would also need to be done in the various other repos that create MSI and bundle installers for bits of the runtime.

@richlander @dleeapho @MichaelSimons

@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added the untriaged New issue has not been triaged by the area owner label Jan 9, 2020
@richlander
Copy link
Member

Interesting idea. I don't have any specific opinion on this.

My two questions would be:

  • Are there any downsides to this? Could we rely on this approach for 3.1 lifetime?
  • Are any other teams at MSFT using this approach?

The answers to that would help me build up confidence on the approach.

@voronoipotato
Copy link

Hoping I'm not stepping on your space by commenting here as a consumer...

As to the first point, as a user who loves their Surface Pro X, I have installed many programs successfully with 32 bit installers. There are no downsides I have experienced, admittedly this is anecdotal. I would have no issue with relying on that for even my human lifetime, as the battery and performance impacts of installers are negligible as they are a one time cost and rarely run longer than 20 minutes. The emulation is automagic and requires no interaction from the user, and it works pretty well for short running, or run once programs. The emulation under very interactive workloads can be a bit visually choppy, say for example vscode, but an installer should not matter at all.

As to the second point, ¯_(ツ)_/¯ . They may rely on .net, so this could theoretically be a chicken and egg problem. I don't work at MSFT so I'm a poor resource for that :).

Why I care

My work was considering the Surface Pro X for a field device as one of many possible options, however the lack of support definitely shaped the advice I was able to give. I have personally bought and love the device, and I think it has a tremendous value proposition however it's a very hard sell without a smooth process for developing custom software. The battery life is part of what makes it viable as a field device, however when software emulation drains the battery it invalidates that. The one shot cost of a 32 bit installer by contrast is not a concern.

@richlander
Copy link
Member

Hoping I'm not stepping on your space by commenting here as a consumer...

Quite the opposite. We APPRECIATE it. Thanks!

relying on that for even my human lifetime

I hope we don't need to reason about this issue for quite that long!

As to the first point, as a user who loves their Surface Pro X

Very cool. We're doing this work for the Surface Pro X folks. We had always planned to enable this platform, and have managed to get it to the right priority level in our backlog. I'm hoping that they buy my team a cake when we ship this support.

@voronoipotato
Copy link

If they don't I will.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
Development

Successfully merging a pull request may close this issue.

5 participants