Installers should be aware of multi-arch OSes and warn users as appropriate

[vitek-karas]

Most OSes are becoming multi-arch, in the sense that it's possible to run multiple different architectures on the same machine. For example:

• Windows x64 and x86 - existing problem
• Apple M1 x64 and arm64
• Windows x64 and arm64
• and so on (pending future support for platform/architecture matrix)

On all platforms, the default installers will put the location of dotnet into PATH. But if they install the second architecture, the resulting experience is confusing to the users. For example:

• Install x64 .NET 5 on Windows (C:\Program Files\dotnet is added to the PATH)
• Install x86 .NET 3.1 on Windows (C:\Program Files (x86)\dotnet is appended to the PATH)
  The end result is that both x64 and x86 are on PATH, but the first one wins, so running:
  dotnet --info
  Will run the x64 version and only list 5.0 as installed. Also dotnet app.dll won't work on 3.1 app, even though it was just installed.

Installers should recognize that another architecture is already on the machine and that it's on PATH and inform user about this behavior.

See dotnet/runtime#3820 (comment) for another great example of this problem and how installer warning would help.

[vitek-karas]

/cc @Rick-Anderson

[vitek-karas]

@richlander something like this would be needed for Apple M1 work, if we decide to go side-by-side.

[marcpopMSFT]

Nikola and Jacques are already discussing how to handle this for x86 and x64. There's a separate discussion for what to do with apple M1 for arm64 and x64 tracked here: dotnet/sdk#16896

[richlander]

There are two aspects of this:

• How do we handle the PATH for multiple .NET architectures on a machine?
• How do we handle .NET versions that are not available/legal for a given architecture?

Here is my proposal:

• No longer automatically add the non-native .NET install directory to the PATH.
• Teach the muxer to see all .NET installs (installed to the normal location) on the machine for the purpose of good error messages.
• Write guidance on how someone should target both .NET Core 3.1 (x64) and .NET 6 (Arm64) on the same machine. Say they are working on two different apps, day in and day out. How do they make that efficient and delightful? This might inspire/require us to make more product changes.

[rickbrew]

Related to this, installation is pretty borked on ARM64 right now (5.0.8).

If you start clean (no .NET installed), and install .NET 5.0.8 x64, it dumps itself into C:\Program Files. At this point, NETCoreCheck (which uses nethost.dll) doesn't function correctly, returning EXIT_FAILURE_HOSTFXREXPORTS (0x3003 / 12291). From looking at the code, this indicates either a LoadLibraryW or GetProcAddress failure (probably the former) with hostfxr.dll https://github.com/dotnet/deployment-tools/blob/3c246e582164af60a222930a2073ba2e1fa6b807/src/clickonce/native/projects/NetCoreCheck/NetCoreCheck.cpp#L39

And then if you install .NET Runtime arm64 + .NET Desktop Runtime arm64 (you have to install both because of dotnet/windowsdesktop#1823 ), you still get the error! This is completely preventing Paint.NET from being able to make heads or tails of the .NET installation status, and it can't proceed. Worse, I'm not even sure what I can or should do to be able to make things work on end-user's systems. I can't detect the installation of the runtime properly, so I can't just plow ahead with installation of the app.

(Note that the x64 version of NETCoreCheck is able to detect the .NET 5.0.8 x64 installation and returns 0 (success) just fine ... but that doesn't help either!)

Any advice on what to do? This is real end-user issue being reported right now: https://forums.getpaint.net/topic/118486-paintnet-43-alpha-build-7881/?do=findComment&comment=585096

[richlander]

Totally get it and agree. That's what this spec is focused on and that we are still working on for .NET 6. dotnet/designs#217

[rickbrew]

Is there any guidance on what to do for Desktop ARM64 apps today? Right now, if .NET x64 is installed, I simply don't know what to do on ARM64. I can't tell users to uninstall (or automate it) it because that could break other apps.

[joeloff]

We're going to broken for some things no matter what unless Windows fix things like the registry. Right now, if you have an x64 and and arm64 copy of an application, they would both default to writing to the 64-bit registry view. Since there is only one, they'll stomp on each other.

The whole installer database is managed in the registry as well so SxS install will just over write and corrupt the database.

[richlander]

Right. The responsibility is on the app (or framework) developer currently.

[rickbrew]

I think the only solution right now for ARM64 is to avoid framework-dependent deployment.

Bandwidth-wise that should be OK because I expect ARM64 to be a very small percentage of users at this point.