[bug][dotnet-sdk] binary linked is incorrect for x64 systems

[isen-ng]

When I used your bug report template, GitHub ALWAYS returns 400 when posting a new issue (I've tried using chrome, ff and safari). However the feature template works when I tested it. So... yea.

---

• I understand that if I ignore these instructions, my issue may be closed without review.
• I have retried my command with --force.
• I ran brew update-reset && brew update and retried my command.
• I ran brew doctor, fixed as many issues as possible and retried my command.
• I have checked the instructions for reporting bugs.
• I made doubly sure this is not a checksum does not match error.

Description of issue

The current dotnet-sdk correctly links the dotnet binary for arm64 systems ,

binary "/usr/local/share/dotnet/dotnet"

However, this is incorrect for x64 systems because the dotnet executable is installed in /usr/local/share/dotnet/x64/dotnet instead.

This can be fixed by:

cask "dotnet-sdk" do
  ...
  link = Hardware::CPU.intel? ? "/usr/local/share/dotnet/x64/dotnet" : "/usr/local/share/dotnet/dotnet"
  ...
  binary link.to_s

Command that failed

dotnet

Output of failed command

$ dotnet
-bash: dotnet: command not found

Output of brew doctor --verbose

Really just a bunch of warnings not related to this

Output of brew tap

$ brew tap
homebrew/cask
homebrew/core
isen-ng/dotnet-sdk-versions

[SMillerDev]

Is this actually intentional upstream? It seems like a bug that the architecture is missing in that path

[isen-ng]

Hmm, should I create an issue on the dotnet repo to see what they say?

[SMillerDev]

Might be good before we have to change this back and forth

[isen-ng]

Ticket reference: dotnet/core#6930

[miccal]

This is a little odd -- I updated dotnet and dotnet-sdk in #114523 and #114522 with the new binary path for Intel, and they both failed the CI tests with:

Error: It seems the symlink source '/usr/local/share/dotnet/x64/dotnet' is not there.

I also updated dotnet-preview and dotnet-sdk-preview in Homebrew/homebrew-cask-versions#12561 and Homebrew/homebrew-cask-versions#12562 with the original binary paths, and they both passed the CI tests.

So, it appears that the pkg installers are NOT adding the x64 to the path for the binaries?

[isen-ng]

This is odd indeed because the new path for x64 are confirmed by the dotnet-core team in the other ticket.
Let me take a look at your CI and try to figure this out.

Edit: I checked your CI and read their design principals and i have a strong suspicion on what is going on. Let me test my suspicion.

[isen-ng]

So, after reading the design principals, and running some tests of my own, I discovered these:

1. binary "/usr/local/share/dotnet/dotnet" is correct
2. The installer package installs the dotnet executable to /usr/local/share/dotnet/x64/dotnet if and only if
   1. package is x64
   2. host architecture is arm64

This cask does not need to care about this situation because this cask only maintains the latest version, which always has both x64 and arm64 support.

That said, the line binary "/usr/local/share/dotnet/dotnet" is redundant because the package already adds the installation path to the $PATH by putting files in /etc/paths.d. It's really up to you guys if you want to remove the binary line or not but I think this ticket is now redundant.

Closing! And thank you for investigating this with me!