Running a .NET 5 project on macOS M1 with .NET 6 leads to confusing error message #59168
Comments
dotnet-issue-labeler
bot
added
area-Host
untriaged
|
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov Issue DetailsSteps to reproduce:
I would expect to see a better error message, either indicating that .NET 5 is not installed, or that an available SDK/runtime is not available. Interestingly enough, even with a rollForward policy of major, it still fails with the same error message. global.json: {
"sdk": {
"allowPrerelease": true,
"rollForward": "major"
}
}
|
|
cc @ericstj |
|
Here are the "instructions" on how to configure your machine today. |
|
@richlander it's not clear from the report that folks are trying to do x64 on ARM64 here. My impression is that this is plain ARM64 but maybe @vcsjones can confirm. cc @sfoslund who's doing work on MAC installers for ARM64. |
|
I see, twitter has more info 😆 https://twitter.com/vcsjones/status/1438155493990707207?s=20 Still looks like this might be a host or host deployment issue. I would expect plain-old ARM64 to "just work" and tell folks to either install a 5.0 shared framework or let them roll-forward (if that's what their runtimeconfig says). |
Right. This is just trying to use ARM64 .NET 6 to run a .NET 5 TFM app. I would expect the roll forward to work, but it does not. For the non-rollforward case the error is very unclear. |
|
I'm surprised this wouldn't fail earlier. How is @vcsjones Does just plain "dotnet build" succeed without an problems? |
@agocke It does. The exact project I am using is here: https://gist.github.com/vcsjones/1fef26b5a9ad4bfe934425b272d56797
The |
|
Thanks, I'll try to figure out what's going on using my M1. I assume that the problem is that the build is publishing the .NET 5 apphost, which is only built for x64. Then, when it tries to run on .NET 6, the runtime is ARM64, so the load fails. I suspect the only option here is to avoid using the apphost for .NET 5 apps, but that would break non-roll-forward scenarios. |
|
@vcsjones I just tried this with RC2 and can't replicate the problem -- it's possible an SDK change to fix I'm using Could you try an RC2 build from https://github.com/dotnet/installer and see if that fixes the problem? Sorry, getting everything sorted for emulation has been a long and complicated process. |
|
Still fails for me. Something I want to call out though because I didn't stress it enough in the original post: this is on macOS 12 (Monterey) beta 21A5506j. Just for kicks I tried a nightly: Just to make sure I am in a known good state: is |
|
Hmm, I'm on Big Sur, but it's possible that I'm the one insufficiently clearing my machine install. |
|
Yup, that was it. I hadn't fully deleted my machine install -- this now fails. However, I can get it to run by using I think this is the 5.0 apphost. Unfortunately it's x64 only, so if we start the runtime with it we'll be stuck in x64 mode, even if roll forward would work.
|
|
@vcsjones Is there a reason you decided to enable roll-forward rather than switching to net6.0 TFM? Or installing the net5.0 runtime? |
I just bumped the TFM but I will admit I wasted a bit of time getting detoured by this. I don't really expect it to work now that I understand what is happening, but it took a while to get there. I only called out rollForward because I would expect that to work. Why would it load the .NET 5 AppHost if I should be rolling forward to 6? (Keep in mind I have a very naive understanding with how this works). Here are the events that led to this:
My hope is that at least this error path can have better output for folks. |
|
Makes sense. I think our intended path was for you to install the 5.0 runtime instead of enabling roll forward. This is the message I get if I run the app without roll forward: I grant you -- doing a dual install of ARM64 .NET 6 and x64 .NET 5 is not easy right now (because of dotnet/installer#11164), but I think that if that is fixed, that seems like a better path. |
That's not the error that I am getting. Without roll forward I still get the obtuse "libhostfxr.dylib" experience. With no This is from the nightly.
|
|
@agocke if I got your experience then I don't think I would have ended up filing an issue. I don't want to get too fixated on roll forward because the problem occurs for me roll forward or not. |
|
Ugh, got my x64 and arm64 copy screwed up again. I get a slightly different, but still not great error message, because I have My error message is: Unfortunately this is still very misleading. |
|
Should we change the SDK when run from ARM64 host? Seems to me like it shouldn’t be leading users down this path without error. The SDK knows what Host RIDs are supported on different target frameworks. |
|
We actually did change SDK to adapt to these cases. Originally running ARM64 SDK always produced ARM64 host - even for downlevel apps. With the changes SDK knows to target x64 for downlevel apps. But that assumes that x64 framework is installed on the machine (actually it assumes that the target framework is installed, .NET 5 only ships as x64 for macOS). .NET 6 SDK doesn't know if .NET 5 is installed on the machine, and I don't think it should try to figure that out. If the framework is missing the host will fail. The error messages are not good in this case, unfortunately we didn't manage to improve those experiences in .NET 6. The tracking issue is #56146, this specific case is very close to #51102. |
|
Yeah I'm going to close this as a dup of #51102 In this case it's not just error message -- I think we also try to load a hostfxr with the wrong bitness, which presumably the apphost will need to guard against somehow. |
I would very much like to avoid looking at random binaries on disk and trying to guess their architecture (especially on mac with fat binaries and so on) - especially from the apphost itself (should be as small and as simple as possible). I looked into this a little bit - on Windows this is "easy" because the LoadLibrary fails with a specific error code. Unfortunately on Linux/macOS I could not find any docs about what error code |
|
If you want you can install the 6.0 x64 version of dotnet on mac and it will be installed to I believe OmniSharp is making updates to make it aware of both arm64 and x64 dotnet SDKs. @JoeRobich is that correct? |
|
@ericstj, that certainly is a stop gap solution for the time being. However, I would like to find if MS is considering any mitigation to this ARM/x64 mismatch / mismatch to allow full benefits of M1 power to us DotNet core lovers. |
|
@ericstj The C# extension is waiting to see if this becomes a common problem for our users or if they simply move to working from the arm64 SDK. FYI @nohwnd @dong82 I would recommend letting the arm64 CLI use the dotnet name and choose a different alias for the x64 version, since I would expect it to become less and less useful. |
|
@dong82 I understand the need for downlevel runtimes, but there should be much less need for downlevel SDKs. The .NET 6 SDK should be mostly backward compatible. Meaning that you can use .NET 6 SDK to build .NET 5/.NET Core 3.1 apps. Both the SDK and runtime should now be updated such that trying to run the downlevel apps will pick the correct runtime (x64). The only known limitation currently is certain specifics around |
|
@vitek-karas, the important key is "mostly backward compatible". I might bite a bullet and try net6.0 as a single SDK on my personal M1 Mac. Until we could guarantee 100% compatibility, the team wouldn't be able to push Mac developers to eliminate the older SDKs. Although it is not my favorite, the best alternative seems to have Mac developers use x64 net6.0 for the time being. |
|
Heya, I just got here because I have the exact same error as @vcsjones. I kind of skim read this whole thread and I'm left with the conclusion that it was closed without any guidance or a fix or any advice on how to overcome this problem. What am I missing or is this broken state the expected behaviour? |
|
@dong82 Just to make sure I understand and to set the right expectations. Your main issue is that VS Code doesn't seamlessly support multiple SDKs across architectures, right? As for the rest:
@dustinmoris can you please be a bit more specific what is the "broken state"? Please note that for the various runtimes to coexist you need to update them to the latest versions as described here: dotnet/sdk#22380. |
|
I am on an M1. I only have the latest .NET 6 SDK installed. I have opened a .NET 5 project and added |
|
@dustinmoris thanks for the description. There are 4 different runtimes which are supported on Apple Silicon (at least I think):
Currently the SDK is designed to work like this:
What we didn't do and maybe we should is to take into account dotnet --roll-forward Major app.dllThat should work - assuming the app has no native dependencies (as those are most likely x64 and would fail to load in a arm64 process). |
|
mhh interesting. Yes I think what you described as "what we didn't do and maybe we should..." is kind of what I thought RollForward was doing ^^ |
|
@vitek-karas, thanks for the detailed updates. --roll-forward seems like an interesting approach. In the meantime, I will write down my approach to figure out the problem.
I think the missing one dotnet binary pointed out at Step 6 was the problem that confused me the most the whole time. --roll-forward seems like the ultimate approach but if you could update the installer to ensure the removal of 3.1 and 5.0 and also ensure the placement of dotnet binary for version 6.0 would be a quicker and cheaper solution, in my opinion. |
|
I'm unable to get past this issue even with I've tried all the solutions here, including the |
|
@zaneclaes Can you please describe in more detail what does this mean "Attempting to start any of the 3 different projects"? The error you get would typically mean that you're trying to use ARM64 executable (either
In the case of |
|
Thanks for looking into it, @vitek-karas ...
I merely meant to say that I actively contribute to 3 different dotnet projects (with different dependencies), and none of them work — so to your point about "either dotnet or the app's app executable," I was assuming the former.
Even after re-installing 6.0.1 multiple times it still points to the 5.0.4 install: Though the binary is correct: I tried manually editing the install location file to
Here's the full Finally, note this is a brand new computer (just got the M1 laptop). I started by installing dotnet 5, then tried to also install dotnet 6.
|
What I was curious about is what exact command is failing to run (as that can make a difference in figuring out the root cause). Sorry - I asked the wrong question - in the Note that the one command which is currently known to not work (yet) is |
Ah, sorry. Is
There's also |
|
@zaneclaes, There is no such folder as
|
Hm, @vitek-karas told me to look for that folder — so it sounds like it is expected to exist. Maybe that was the problem you had? Note that, as I mentioned in my last post, |
|
I'm actually not sure about What is the exact command line, just Per dotnet/sdk#21404 it should more or less work as expected. The new installers (so anything .NET 6 and the latest of .NET 5 and .NET 3.1) should create |
|
@zaneclaes, |
|
@dong82 Based on the output of your The fact that |
No:
Same error.
I'm not sure about that flag, but running |
|
@vitek-karas, |
|
@zaneclaes that is weird - would it be possible to grab a host trace? Can you also try @dong82 I don't know why your |
facepalm I blindly copied your last post, which had said to use |
|
@vitek-karas |
|
@vitek-karas
The tricky parts are misleading |
|
Anything below 3.1.415 and 5.0.403 is not supported on M1 hardware (because it installs into the wrong location). As per the issues referenced above, the recommended action is to:
With that the Step 6. where you say it removed the Again, step 9. is expected and won't be fixed. On top of that Step 10. The fact that the runtime version differs from the SDK version is expected - I don't know if these are the versions to be expected, but there's no rule which says that the SDK and runtime versions have to match exactly (typically they don't). Step 14. is currently expected and by design. Without the unsupported versions, you should get an error about missing framework. Ideally when we fix all of the details, this error should contain the fact that you have that framework installed in the Happy new year to you as well. |
|
@vitek-karas, As you mentioned, The problems on Step 6 are persistent and I will submit a separate issue for this. Thanks |
ghost
locked as resolved and limited conversation to collaborators
Steps to reproduce:
Install .NET 6 RC1 on an M1 Mac with the ARM64 architecture. Make sure there are no previous installs of .NET.
Try to run a .NET application that targets .NET 5 with
dotnet runYou'll get output that looks like:I would expect to see a better error message, either indicating that .NET 5 is not installed, or that an available SDK/runtime is not available.
Interestingly enough, even with a rollForward policy of major, it still fails with the same error message.
global.json:
{ "sdk": { "allowPrerelease": true, "rollForward": "major" } }The text was updated successfully, but these errors were encountered: