azure-functions-host: Error on build for in-portal functions with NuGet references
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:
- Create simple in-portal function
- 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.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 20 (9 by maintainers)
👍
DOTNET_ADD_GLOBAL_TOOLS_TO_PATH
works nicely. I assume it will be fixed eventually, for now I can continue. Thanks!DOTNET_ADD_GLOBAL_TOOLS_TO_PATH=false worked for me too
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
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?