installer
installer copied to clipboard
dotnet
.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.
- On a macOS machine, using .NET 5 + .NET 3.1 - building an Azure Functions project works fine.
- Downloading and installing the .NET 6 Preview installer( via https://download.visualstudio.microsoft.com/download/pr/9e02abfd-b421-4c43-8541-482f037ed19c/f61bd4f35c444710016db8b5a7206a97/dotnet-sdk-6.0.100-preview.7.21379.14-osx-x64.pkg ), and building using the .NET 6 preview 7 SDK I get the error :
Metadata generation failed. Exit code: '137' Error: 'Failed to initialize CoreCLR, HRESULT: 0x80004005:
/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)
I tried the nightlies, https://aka.ms/dotnet/6.0.1xx/daily/dotnet-sdk-osx-x64.pkg a.k.a. RC2 (and only the SDK). Seems to work there.
@vitek-karas , looks like it's failing to call dotnet from 6.0 from the task here: https://github.com/Azure/azure-functions-host/blob/b5e21770905343a3a58a6614c0a32ec3d80f1860/tools/ExtensionsMetadataGenerator/src/ExtensionsMetadataGenerator/BuildTasks/GenerateFunctionsExtensionsMetadata.cs. Any ideas?
I honestly don't know. I "think" 137 means either manual "kill process" signal, or OOM. But 0x80004005 doesn't mean much (E_FAIL) unfortunately.
Given the install/uninstall - if your machine is in the "bad" state, could you check what versions of hostfxr do you have installed? That is go to /usr/local/share/dotnet/host/fxr and look at all the directories there - they enumerate the installed versions. Does it have 6.0 there? Does it have 6.0 there even if you uninstall 6.0?
Similarly check the dotnet executable itself, what version it is. Running strings /usr/local/share/dotnet/dotnet | grep @(#)
Yes, 6.0 is in host/fxr after I install it.
drwxr-xr-x 3 root wheel 96 Oct 19 2020 5.0.0
drwxr-xr-x 3 root wheel 96 Aug 13 00:37 5.0.10
drwxr-xr-x 3 root wheel 96 Dec 12 2020 5.0.2
drwxr-xr-x 3 root wheel 96 Jan 23 2021 5.0.3
drwxr-xr-x 3 root wheel 96 Sep 9 11:08 5.0.9
drwxr-xr-x 3 root wheel 96 Sep 1 20:12 6.0.0-rc.1.21451.13
drwxr-xr-x 3 root wheel 96 Sep 7 18:22 6.0.0-rc.2.21457.6
The uninstall process on macOS is just a recommendation to remove a bunch of folders, so I've made sure to remove any folder named in 6.0.0-* in any of the folders in that document. Also, that document is in the wrong since the fx/runtime versions don't match the SDK versions, but that's a different story.
What I've found so far, is that after any install of .NET 6 preview/rc, I have to re-install .NET 5 to fix it. I don't really have to uninstall .NET 6 at all. As long as i run the .NET 5 installer after the .NET 6 installer, all is good.
When I:
- Install .NET 6 RC 1
- Install .NET 6 RC 2
- Install .NET 5
➜ ~ strings /usr/local/share/dotnet/dotnet | grep "@(#)"
@(#)Version 5.0.1021.41214 @Commit: e1825b4928afa9455cc51e1de2b2e66c8be3018d
➜ ~ dotnet --version
6.0.100-rc.2.21458.9
When I install .NET 6 RC1 after .NET 5 and .NET 6 RC2:
➜ ~ strings /usr/local/share/dotnet/dotnet | grep "@(#)"
@(#)Version 6.0.21.45113 @Commit: d7619cd4b165c13430484e381042f055d4c5a9c7
➜ ~ dotnet --version
6.0.100-rc.2.21458.9
Even though I also have RC2 installed, this seems to link the the executable to a RC1 version (?)
I can explain this behavior, but not the failure (that one is still a mystery to me).
Installing a version will very likely (I would have to defer to the installer people here) simply overwrite the dotnet executable. This means that whichever version you installed last is the one you're going to get. This should have very little effect on functionality (the dotnet executable changes very little between releases and so it's expected that older one works with newer SDK and vice versa). (I'll try to validate this behavior)
dotnet --version doesn't print the version of the dotnet itself, it actually prints the version of the "active" .NET SDK. Ignoring some details, this is by default the latest version you have installed.
hostfxr is yet another piece of the puzzle, regardless of dotnet executable itself, or the version of the app, or the version of the SDK, we always load the latest available version. So unless you delete the directory from host/fxr even installing the 5.0 over it will not force the 5.0 version to be used. This might be interesting to try (remove everything from 6.0 except for the hostfxr and see if the problem still occurs).
Yep, familiar with how the SDK and it's rollForward mechanism works at least. Interesting to know that older exes should work with newer SDKs, though. That was new to me.
Not sure, but according to this, building .NET 6 functions requires both .NET 3.1 & .NET 6.
Note: Currently you need both the .NET Core 3.1 and .NET 6.0 SDKs installed to build isolated function apps. You only need .NET 6.0 to run the apps.
Not sure if the .NET 6 installer impacts .NET 3.1 in some way or fashion that borks that requirement for Azure Function builds. From what I can see in the folder, all 3.1 folders are kept, so it must be some other black magic.
Re /fxr:
Re-installing .NET 5 (or even .NET 3.1) fixes the issue, both if I still keep the .NET 6 or if I uninstall .NET 6 folders. So a stable .NET installer is able to do some sort of fix for a problem introduced by installing .NET 6.
I could be wrong, but since deleting all .NET 6 folders does not help, the only thing left I can see as remnants that could be of issue is that the exe is still .NET 6.
@(#)Version 6.0.21.45113 @Commit: d7619cd4b165c13430484e381042f055d4c5a9c7
That said, I'm not able to reproduce it using a GitHub action repro:https://github.com/johnkors/dotnet6-sdk-w-functions/runs/3631622491
whichever version you installed last is the one you're going to get.
That's not the way most installer technology works. Most components / products have a version that is honored regardless of order of installation. It's important for shared components. This can happen at the product / component / resource level. I know for MSI it happens at all of these levels. I'm no Mac expert, but it seems to happen at least at the component level, as I see packages can have a property BundleIsVersionChecked. Should be a simple test for someone with a mac handy: install 6.0 then install 3.1 and check the version of the host. If it is 3.1, file a bug. I believe the top-level bundle can control this with BundleIsVersionChecked property so it could be a fix to the SDK bundle, just don't know the default and don't have a mac handy to check. cc @sfoslund @NikolaMilosavljevic @joeloff
install 6.0 then install 3.1 and check the version of the host. If it is 3.1, file a bug
Right, I thought this would be the repo for that. If not, where do I file it?
@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).
Ok, gotcha. Or even breaking 3.1, since I only get the build error for Functions which have a 3.1 requirement.
I'm sorry - what I said sounded like I think that the installer doesn't do it correctly. I definitely hope it does it correctly. I just checked on Linux, and the package manager installer on Ubuntu handles this correctly - which is great.
On the other hand dotnet-install.sh doesn't handle this correctly and overwrites - I just tried installing 5.0 followed by 3.1 and the dotnet executable is the 3.1 version.
Based on some of the comments above from @johnkors it seems to behave that way on his machine. Specifically this:
Install .NET 6 RC 1 Install .NET 6 RC 2 Install .NET 5
➜ ~ strings /usr/local/share/dotnet/dotnet | grep "@(#)"@(#)Version 5.0.1021.41214 @Commit: e1825b4928afa9455cc51e1de2b2e66c8be3018d➜ ~ dotnet --version6.0.100-rc.2.21458.9
Aside from the installation story (which is definitely not the main issue here): Can you try this?
export DOTNET_TRACE=1
export DOTNET_TRACE_FILE=host.txt
The host.txt should contained detailed logging information about what was executed and with which version. The file may contain information about the local machine (paths, env. variables) and about the current user, please be aware of this if you want to share it here. It would be interesting to look at lines like --- Invoked dotnet (there should be one for each invocation of dotnet executable, and it will include version info as well as command line). With this I would then try to run the failing dotnet invocation separately from command line (without the outer layers of dotnet build and such). Basically trying to isolate the repro for the failure.
@johnkors in the other issue you also mention that this doesn't happen with RC2: https://github.com/Azure/azure-webjobs-sdk/issues/2755#issuecomment-915926088 Does it mean that this only happens when installing .NET 6 RC1? (and not when instead using .NET 6 RC2)
Actually one other simple thing to try:
dotnet new console -f netcoreapp3.1
dotnet build
dotnet ./bin/Debug/netcoreapp3.1/app.dll
(I'm trying to get a local repro, but no luck so far)
dotnet new console -f netcoreapp3.1
☝️ No, this builds fine. There isn't an a general issue with building netcoreapp3.1 apps. There's only an issue with building Azure Functions projects using the Azure SDK nugets, which deep down in their tooling tries to use the dotnet 3.1 SDK for some reason (even if the Function project targets .net 5 or 6!). Deep down in the microsoft.azure.webjobs.script.extensionsmetadatagenerator nuget, there are some msbuild tasks that tries to generate a json file.
/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]
I've noe idea if it's the case, but I assume this error is from the code that tries to launch the 3.1 SDK ☝️ They haven't really answered yet.
Does it mean that this only happens when installing .NET 6 RC1? (and not when instead using .NET 6 RC2)
Yes, if I install RC2 after RC1, the build of the Azure Function project does not fail with the "Failed to init CoreCLR" error and builds as expected. I'm not sure if something has been fixed between RC1 and RC2, but I'm at least unblocked with using a nightly RC2 build atm.
export DOTNET_TRACE=1 export DOTNET_TRACE_FILE=host.txt
Setting these did not produce a host.txt during builds? I tried setting another path as well, but nothing produced.
Btw, I'm installing via the website and using the macOS installers from https://dot.net and the x64 version specifically.
As another pointer to the RC1 installer (or the RC1 exe) being the issue. If I install RC1 then RC2, then uninstall RC2 (removing all RC2 folders), the build works.
➜ SomeFunction git:(master) ✗ strings /usr/local/share/dotnet/dotnet | grep "@(#)"
@(#)Version 6.0.21.46725 @Commit: 70f8bb2098f8a946888ee81b4e51aa71d573b407
➜ SomeFunction git:(master) ✗ dotnet --version
6.0.100-rc.1.21458.32
➜ SomeFunction git:(master) ✗ dotnet build
Microsoft (R) Build Engine version 17.0.0-preview-21458-01+2c5510013 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.
Determining projects to restore...
All projects are up-to-date for restore.
You are using a preview version of .NET. See: https://aka.ms/dotnet-core-preview
SomeFunction -> /Users/johnkors/kode/temp/dotnet6-sdk-w-functions/SomeFunction/bin/Debug/net5.0/SomeFunction.dll
Build succeeded.
I also get this odd warning only once (on the first restore) if I try to clear local caches first.
The ExtensionsMetadataGenerator package was not imported correctly. Are you missing '/Users/johnkors/.nuget/packages/microsoft.azure.webjobs.script.extensionsmetadatagenerator/1.2.2/build/Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator.targets' or '/Users/johnkors/.nuget/packages/microsoft.azure.webjobs.script.extensionsmetadatagenerator/1.2.2/build/Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator.props'
➜ SomeFunction git:(master) ✗ rm -rf /Users/johnkors/.nuget/packages/microsoft.azure.webjobs.script.extensionsmetadatagenerator/
➜ SomeFunction git:(master) ✗ dotnet build --no-cache
Microsoft (R) Build Engine version 17.0.0-preview-21458-01+2c5510013 for .NET
Copyright (C) Microsoft Corporation. All rights reserved.
/Users/johnkors/.nuget/packages/microsoft.net.sdk.functions/3.0.13/build/Microsoft.NET.Sdk.Functions.targets(74,5): warning : The ExtensionsMetadataGenerator package was not imported correctly. Are you missing '/Users/johnkors/.nuget/packages/microsoft.azure.webjobs.script.extensionsmetadatagenerator/1.2.2/build/Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator.targets' or '/Users/johnkors/.nuget/packages/microsoft.azure.webjobs.script.extensionsmetadatagenerator/1.2.2/build/Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator.props'? [/Users/johnkors/kode/temp/dotnet6-sdk-w-functions/SomeFunction/SomeFunction.csproj]
Determining projects to restore...
Ok, great. So RTM also has this issue.
/Users/johnkors/.nuget/packages/microsoft.azure.webjobs.script.extensionsmetadatagenerator/4.0.1/build/Microsoft.Azure.WebJobs.Script.ExtensionsMetadataGenerator.targets(37,5): error : Metadata generation failed. Exit code: '137' Error: 'Failed to initialize CoreCLR, HRESULT: 0x80004005' [/var/folders/27/l893mwzn2611z7x3w_006_wr0000gn/T/erlqzr1n.mqi/WorkerExtensions.csproj] 1 Warning(s) 1 Error(s) Time Elapsed 00:00:05.53
➜ src git:(chore/update-to-dotnet6) ✗ dotnet --version 6.0.100 ➜ src git:(chore/update-to-dotnet6) ✗ strings /usr/local/share/dotnet/dotnet | grep "@(#)" @(#)Version 6.0.21.52210 @Commit: 4822e3c3aa77eb82b2fb33c9321f923cf11ddde6
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 (R) Build Engine version 17.0.0+c9eb9dd64 for .NET Copyright (C) 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]
Ok, I caved and just deleted all earlier SDKs. No idea why this fails, and don't have time to dig further.
Installing .NET 6 from a clean slate works.
So I've got the issue as well, I was thinking it was tied to my updating azure-functions-core-tools to v4. I'd be happy to guinea pig potential solutions.
Runtime Environment: OS Name: Mac OS X OS Version: 12.0.1 OS Platform: Monterey RID: osx.11.0-x64 Base Path: /usr/local/share/dotnet/sdk/6.0.100/
my installed SDKs: 2.1.402 [/usr/local/share/dotnet/sdk] 2.1.505 [/usr/local/share/dotnet/sdk] 2.2.104 [/usr/local/share/dotnet/sdk] 2.2.300 [/usr/local/share/dotnet/sdk] 3.0.100 [/usr/local/share/dotnet/sdk] 3.1.300 [/usr/local/share/dotnet/sdk] 5.0.101 [/usr/local/share/dotnet/sdk] 5.0.402 [/usr/local/share/dotnet/sdk] 5.0.403 [/usr/local/share/dotnet/sdk] 6.0.100 [/usr/local/share/dotnet/sdk]
my runtimes: Microsoft.AspNetCore.All 2.1.4 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.All] Microsoft.AspNetCore.All 2.1.9 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.All] Microsoft.AspNetCore.All 2.2.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.All] Microsoft.AspNetCore.All 2.2.5 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.All] Microsoft.AspNetCore.App 2.1.4 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 2.1.9 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 2.2.2 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 2.2.5 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 3.0.0 [/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 5.0.1 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 5.0.11 [/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 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 2.1.4 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 2.1.9 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 2.1.18 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 2.2.2 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 2.2.5 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 3.0.0 [/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 5.0.1 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 5.0.11 [/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 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
@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?
I tried your repro https://github.com/johnkors/dotnet6-sdk-w-functions/tree/master/SomeFunction on my Intel mac and couldn't get it to repro. I was using all the latest releases of 3.1, 5.0, and 6.0. My build was successful both before and after installing 6.0.
If anyone has an active repro, then steps to do are capture a binlog (dotnet build /bl) and host trace (using COREHOST_* variables @vitek-karas mentions)
I reproduced a similar bug today and it seemed to be caused by bad state of the file descriptor for dotnet. For me copying and replacing dotnet inexplicably fixes it. We're still working on understanding the "why" behind that.
For anyone in this state, try the following and let me know if it fixes it for you:
cd /usr/local/share/dotnet
sudo cp dotnet dotnet.copy && rm dotnet && mv dotnet.copy dotnet
Chiming back in here after the US holiday week has past. If anyone has an active repro of this, please try the workaround above. Another thing that fixed it for me was a reboot of the machine. The best we've been able to determine is that MacOS caches the signature for the dotnet executable after it has been run once. If an installer replaces the dotnet through a copy step (as is done by the dotnet-install scripts) then we found that MacOS will fail to launch the process since the new binary does not match the cached signature. Rebooting, or moving the file and replacing it with a copy, seems to refresh the cached signature.
We filed https://github.com/dotnet/install-scripts/issues/232 as a result of this and hope that the install scripts might change their behavior.
Ok, but as mentioned — I installed via downloading the pkgs. Did not use the install scripts.