Azure-functions-host: Error on build for in-portal functions with NuGet references

[antonGritsenko]

Investigative information

Please provide the following:

• Timestamp: 2020-04-17T13:10:40.297
• Function App version: 3.0
• Function App name: azsometest22
• Function name(s) (as appropriate): SomeTest
• Invocation ID: 9c2cedf0-5596-419f-aaef-190d1afd7744
• Region: Central US, West Europe

Repro steps

Provide the steps required to reproduce the problem:

1. Create simple in-portal function
2. Add function.proj with content:

<Project Sdk="Microsoft.NET.Sdk">
    <PropertyGroup>
        <TargetFramework>netstandard2.0</TargetFramework>
    </PropertyGroup>
    <ItemGroup>
        <PackageReference Include="Azure.Storage.Blobs" Version="12.0.0" />
    </ItemGroup>
</Project>

Expected behavior

Build is OK

Actual behavior

Seems to be the #4665 returns

We have a problem in several regions (not sure if it for all, can't test)
Error occurred during the build when you add function.proj with some references to NuGet.

2020-04-17T13:10:40.297 [Information] Compilation failed.
2020-04-17T13:10:41.047 [Information] Executing 'Functions.SomeTest' (Reason='This function was programmatically called via the host APIs.', Id=54c3a466-d592-4853-97c8-d27bcdb9d983)
2020-04-17T13:10:41.063 [Information] Package references have been updated.
2020-04-17T13:10:41.064 [Information] Restoring packages.
2020-04-17T13:10:41.127 [Information] Starting packages restore
2020-04-17T13:10:41.963 [Information] System.UnauthorizedAccessException: Attempted to perform an unauthorized operation.
2020-04-17T13:10:41.963 [Information] at Internal.Win32.RegistryKey.Win32Error(Int32 errorCode, String str)
2020-04-17T13:10:41.963 [Information] at Internal.Win32.RegistryKey.SetValue(String name, String value)
2020-04-17T13:10:41.983 [Information] at System.Environment.SetEnvironmentVariableFromRegistry(String variable, String value, Boolean fromMachine)
2020-04-17T13:10:41.983 [Information] at System.Environment.SetEnvironmentVariable(String variable, String value, EnvironmentVariableTarget target)
2020-04-17T13:10:42.011 [Information] at Microsoft.DotNet.Cli.Utils.EnvironmentProvider.SetEnvironmentVariable(String variable, String value, EnvironmentVariableTarget target)
2020-04-17T13:10:42.011 [Information] at Microsoft.DotNet.ShellShim.WindowsEnvironmentPath.AddPackageExecutablePathToUserPath()
2020-04-17T13:10:42.011 [Information] at Microsoft.DotNet.Configurer.DotnetFirstTimeUseConfigurer.Configure()
2020-04-17T13:10:42.021 [Information] at Microsoft.DotNet.Cli.Program.ConfigureDotNetForFirstTimeUse(IFirstTimeUseNoticeSentinel firstTimeUseNoticeSentinel, IAspNetCertificateSentinel aspNetCertificateSentinel, IFileSentinel toolPathSentinel, Boolean hasSuperUserAccess, DotnetFirstRunConfiguration dotnetFirstRunConfiguration, IEnvironmentProvider environmentProvider)
2020-04-17T13:10:42.021 [Information] at Microsoft.DotNet.Cli.Program.ProcessArgs(String[] args, ITelemetry telemetryClient)
2020-04-17T13:10:42.022 [Information] at Microsoft.DotNet.Cli.Program.Main(String[] args)
2020-04-17T13:10:42.049 [Information] Packages restored.

[antonGritsenko]

note: same works fine few weeks ago

[brettsam]

This does look like #4665 again. Did you try this (from https://github.com/Azure/azure-functions-host/issues/4665#issuecomment-512921553)

While we work on a permanent fix, a known mitigation is to set the following app setting in your Function App:

Name: DOTNET_SKIP_FIRST_TIME_EXPERIENCE
Value: 1

@soninaren / @fabiocav -- I don't recall what the issue was here. Is this something in App Service that needed to be changed?

[antonGritsenko]

@brettsam yeah, sorry, forget to mention. Yes, I did try this, same error.

[seesharprun]

I'm getting this same issue with multiple functions. The app setting did not work.

[mkarthik156]

@brettsam yeah, sorry, forget to mention. Yes, I did try this, same error.

Earlier the same issue occurred in Function app version ~2 months back #4665, and the workaround worked back then.
The same issue is back with version ~3.

[SjaaLom]

Is there a workaround for this?

[brettsam]

Can you try an app setting of DOTNET_ADD_GLOBAL_TOOLS_TO_PATH with value false and let us know if that fixes it?

[trevie]

@brettsam, DOTNET_ADD_GLOBAL_TOOLS_TO_PATH=false worked for me.

Specifically, it got AZ-204 Lab 07, Exercise 4, Task 4 working, eliminating my
"[Information] System.UnauthorizedAccessException: Attempted to perform an unauthorized operation."
error which I believe was leading to the
"error CS0246: The type or namespace name 'Azure' could not be found (are you missing a using directive or an assembly reference?)"
errors.

The above worked with and without DOTNET_SKIP_FIRST_TIME_EXPERIENCE=1.

[seesharprun]

The app setting DOTNET_ADD_GLOBAL_TOOLS_TO_PATH works for me too. Now I can resolve NuGet packages in the in-portal editor. Is this the permanent fix or is there another regression fix pending?

[SjaaLom]

👍 DOTNET_ADD_GLOBAL_TOOLS_TO_PATH works nicely. I assume it will be fixed eventually, for now I can continue. Thanks!

[brettsam]

Great, glad to see you all unblocked.

@soninaren -- is this issue understood? Do we have a way to fix it without needing the app setting?

[soninaren]

@brettsam, Not sure what change triggered this issue. We do have a way to fix it without app setting.

We would have set DOTNET_ADD_GLOBAL_TOOLS_TO_PATH at the following locations.

https://github.com/Azure/azure-functions-host/blob/2048b0071c465d9052405056872329b2e9009ae4/src/WebJobs.Script/Description/DotNet/PackageManager.cs#L74

https://github.com/Azure/azure-functions-host/blob/2048b0071c465d9052405056872329b2e9009ae4/src/WebJobs.Script/BindingExtensions/ExtensionsManager.cs#L204

[gianpaolobernardini]

DOTNET_ADD_GLOBAL_TOOLS_TO_PATH=false worked for me too

[krfrost1]

The workaround did not work for the AZ 204 Lab 7 today. Several of us tried the same steps, including both workarounds
DOTNET_ADD_GLOBAL_TOOLS_TO_PATH=false (this was set already when we created the function)
DOTNET_SKIP_FIRST_TIME_EXPERIENCE=true (also tried it with false and not there at all; it made no difference)

Runtime version = ~3
also tried setting it back to ~2, all with the same error.

Is there a workaround that can make this lab work today?

[mhoeger]

Really sorry about the trouble :( confirmed that this issue has been resolved as of 7/10

[houbena]

Same here .. the bug persists even after trying the workarounds mentioned above.

[mhoeger]

@houbena - can you open a new issue with the same level of details as OP so we can investigate?

[brettsam]

I don't think this should be closed. We need to add this to the host itself (see the comment above -- https://github.com/Azure/azure-functions-host/issues/5893#issuecomment-622133356)

[mhoeger]

Ahh got it! I thought this item was tracking when the workaround wasn't working (something about a permission denied error I think) but yeah looks like issue is not resolved - thanks! Bumping up to future sprint

[brettsam]

@mhoeger -- can we make sure this gets in by end-of-sprint? Getting quite a bit of noise from it and it'd be good to have this set up automatically for folks.