installer: .NET 6 installer fails builds of Azure Function projects on macOS

Hi,

this is an odd case first registered here: https://github.com/Azure/azure-webjobs-sdk/issues/2755.

It only happens on macOS on a dev machine, and is not possible to reproduce using the GitHub Actions macOS-11 host.

/Users/johnkors/.nuget/packages/microsoft.azure.webjobs.script.extensionsmetadatagenerator/1.2.0/build/Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator.targets(37,5): warning : Failed to initialize CoreCLR, HRESULT: 0x80004005 [/Users/johnkors/kode/blank/fplbot-org/fplbot/src/FplBot.Functions/FplBot.Functions.csproj] /Users/johnkors/.nuget/packages/microsoft.azure.webjobs.script.extensionsmetadatagenerator/1.2.0/build/Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator.targets(37,5): error : Metadata generation failed. Exit code: ‘137’ Error: ‘Failed to initialize CoreCLR, HRESULT: 0x80004005’ [/Users/johnkors/kode/blank/fplbot-org/fplbot/src/FplBot.Functions/FplBot.Functions.csproj]

  • Uninstalling .NET 6 previews and re-building with .NET 5 SDK still fails with the same error, even when specifying to build with the .NET 5 SDK in a global.json

The only fix I’ve found, is to first uninstall .NET 6 completely, then re-run the .NET 5 installer. So something is off in the .NET 6 installer package, as I suspect as mentioned in the linked issue. That, or somehow uninstalling .NET 6 is incomplete when following the recommended guidelines.

My dev machine is running macOS 11.15 BigSur (x64)

About this issue

  • Original URL
  • State: open
  • Created 3 years ago
  • Comments: 43 (16 by maintainers)

Most upvoted comments

We found a reliable repro using the scripts (and a workaround) but it’s possible pkg installation would hit the same issue. I believe this bug would explain the situation you observed. If anyone is in this state, then running the above workaround should confirm that the problem is not with the binary/host itself, but with the operating system / file system. We did also file an issue with Apple on this, but I don’t have a ticket to link.

@vitek-karas I did confirm your theory that old installers will overwrite the host. https://github.com/dotnet/runtime/issues/61526

That could explain why reinstalling 5.0 is fixing this. Not sure what Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator.targets might be observing in the dotnet shared host though. As @vitek-karas mentioned

This should have very little effect on functionality

@johnkors @badgerowluke – just to confirm, you’re not on an M1 machine, right?

For anyone being hit by this, here are the possible workarounds to be unblocked.

Re-installing .NET 5 after .NET 6 resolves the issue again:

➜ strings /usr/local/share/dotnet/dotnet | grep “@(#)” @(#)Version 6.0.21.52210 @Commit: 4822e3c3aa77eb82b2fb33c9321f923cf11ddde6

[installing .NET 5 after .NET 6]

➜ strings /usr/local/share/dotnet/dotnet | grep “@(#)” @(#)Version 5.0.1221.52207 @Commit: 7211aa01b34bb55ca67bdddd6e80ce23ee201bd2

☝️ Now the .NET 5 executable/launcher is in use instead of the .NET 6 one.

➜ dotnet build Microsoft ® Build Engine version 17.0.0+c9eb9dd64 for .NET Copyright © Microsoft Corporation. All rights reserved.

Determining projects to restore… All projects are up-to-date for restore. WorkerExtensions -> /var/folders/27/l893mwzn2611z7x3w_006_wr0000gn/T/jdhnreq3.l2z/buildout/Microsoft.Azure.Functions.Worker.Extensions.dll

Build succeeded. 0 Warning(s) 0 Error(s)

Time Elapsed 00:00:09.33

My machine:

➜ dotnet --info .NET SDK (reflecting any global.json): Version: 6.0.100 Commit: 9e8b04bbff

Runtime Environment: OS Name: Mac OS X OS Version: 11.0 OS Platform: Darwin RID: osx.11.0-x64 Base Path: /usr/local/share/dotnet/sdk/6.0.100/

Host (useful for support): Version: 6.0.0 Commit: 4822e3c3aa

.NET SDKs installed: 2.1.806 [/usr/local/share/dotnet/sdk] 3.1.103 [/usr/local/share/dotnet/sdk] 3.1.300 [/usr/local/share/dotnet/sdk] 3.1.412 [/usr/local/share/dotnet/sdk] 3.1.413 [/usr/local/share/dotnet/sdk] 5.0.100 [/usr/local/share/dotnet/sdk] 5.0.102 [/usr/local/share/dotnet/sdk] 5.0.200 [/usr/local/share/dotnet/sdk] 5.0.400 [/usr/local/share/dotnet/sdk] 5.0.401 [/usr/local/share/dotnet/sdk] 5.0.403 [/usr/local/share/dotnet/sdk] 6.0.100-rc.2.21468.5 [/usr/local/share/dotnet/sdk] 6.0.100 [/usr/local/share/dotnet/sdk]

.NET runtimes installed: Microsoft.AspNetCore.All 2.1.18 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.All] Microsoft.AspNetCore.App 2.1.18 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 3.1.3 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 3.1.4 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 3.1.18 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 3.1.19 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 5.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 5.0.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 5.0.3 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 5.0.9 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 5.0.10 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 5.0.12 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 6.0.0-rc.1.21452.15 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 6.0.0-rc.2.21467.38 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 6.0.0 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 2.1.18 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 3.1.3 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 3.1.4 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 3.1.18 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 3.1.19 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 5.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 5.0.2 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 5.0.3 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 5.0.9 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 5.0.10 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 5.0.12 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 6.0.0-rc.2.21467.25 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 6.0.0 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

@johnkors I didn’t meant to say this issue was wrong. I just was addressing @vitek-karas side assertion about installer behavior which may not be the root cause of this issue you filed. I was spelling out that it would be clearly wrong if the SDK’s installer didn’t honor version of the host. That would be something that could easily be tested and and very specific bug could be opened to address it (and separate that entire issue from this thread).

I don’t think that’s the root cause here, since you mentioned that 6.0 broke you, so it’s not like you have an older SDK overwriting a newer one. If I had to guess, there is something about the 6.0 fxr that broke 5.0, or possibly the 6.0 host (which is expected to overwrite the older version).