WorkerExtensions.csproj trying to restore from private nuget feed, unsuccessfully #1252

1kevgriff · 2022-12-30T20:34:07Z

I hope this is the right place for this question.

I have this recurring problem with our local Functions app trying to build. We recently moved to .NET 6 Isolated to support some future product features.

On build, I get this error:

1>C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets(132,5): warning : No Authorization header detected
1>Retrying 'FindPackagesByIdAsync' for source 'https://nuget.pkg.github.com/{{ ourorg }}/download/microsoft.azure.webjobs.extensions.durabletask/index.json'.
1>Response status code does not indicate success: 401 (Unauthorized).
1>C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets(132,5): warning : No Authorization header detected
1>C:\Users\kevin\AppData\Local\Temp\l20wov0k.lk5\WorkerExtensions.csproj : error NU1301: Failed to retrieve information about 'Microsoft.Azure.WebJobs.Extensions.DurableTask' from remote source 'https://nuget.pkg.github.com{{ ourorg }}/download/microsoft.azure.webjobs.extensions.durabletask/index.json'.
1>Failed to restore C:\Users\kevin\AppData\Local\Temp\l20wov0k.lk5\WorkerExtensions.csproj (in 5.86 sec).

I'm not sure why WorkerExtensions.csproj is trying to look at our private Nuget feed for that package.

Functions.csproj

<Project Sdk="Microsoft.NET.Sdk">
	<PropertyGroup>
		<TargetFramework>net6.0</TargetFramework>
		<AzureFunctionsVersion>v4</AzureFunctionsVersion>
		<OutputType>Exe</OutputType>
	</PropertyGroup>
	<ItemGroup>
		<PackageReference Include="Microsoft.Azure.Functions.Extensions" Version="1.1.0" />
		<PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.10.0" />
		<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.DurableTask" Version="1.0.0-rc.1" />
		<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.0.13" />
		<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Storage" Version="5.0.1" />
		<PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Timer" Version="4.1.0" />
		<PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.7.0" OutputItemType="Analyzer" />
		<PackageReference Include="Microsoft.DurableTask.Generators" Version="1.0.0-preview.1" OutputItemType="Analyzer" />
	</ItemGroup>

    <!-- other stuff removed for brevity -->

</Project>

The text was updated successfully, but these errors were encountered:

kshyju · 2023-01-05T18:30:57Z

Are you having trouble when trying to build/restore packages using Visual studio? Do you have the nuget.org package source (https://api.nuget.org/v3/index.json) enabled?

If you are trying to restore using "Manage Nuget packages" tab of the project, do you have "nuget.org" package source selected?

ghost · 2023-01-09T19:01:45Z

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

1kevgriff · 2023-01-09T19:28:53Z

@kshyju Regular restore works fine. This is only trying to build our project if our private repo is enabled:

In the above, I usually have to disable our package source for it to work. nuget.org is typically the default (or all if I'm in the nuget explorer)

jviau · 2023-01-09T22:49:49Z

@1kevgriff I believe the issue is that part of the build process will create a temporary project and invoke dotnet restore on that. This target is not inheriting Visual Studio auth for the restore operation. Can you try installing Nuget Credential Provider and trying again? You probably need to include the -netfx switch).

madhavireddythirumuru · 2023-01-10T07:22:34Z

Hi @1kevgriff, I could resolve similar issue by following the below work around steps.

Update package source to use only the public nuget source "https://api.nuget.org/v3/index.json" and not any of the private feeds.
Restore nuget packages and Rebuild the solution/project.
When build is successful, change the package source back to your private feed.
Now build the solution once again.
This should solve the problem

One more alternative is :

Create a similar project with same dependencies in a separate solution with package source as public nuget feed.
Build the solution.
Change the package source to private nuget feed and rebuild the solution
Now go the previous solution where this issue happened first and rebuild the solution (with out changing the feed)
Build will be successful this time.

I hope these steps would help you resolve the issue.

1kevgriff · 2023-01-12T19:42:15Z

@1kevgriff I believe the issue is that part of the build process will create a temporary project and invoke dotnet restore on that. This target is not inheriting Visual Studio auth for the restore operation. Can you try installing Nuget Credential Provider and trying again? You probably need to include the -netfx switch).

I installed Nuget Credential Provider but it looks like I'm still having the same issue. I'm not entirely sure if there is another step after the install.

After the install, I removed the private repo and re-added it within VS 2022. But no help.

jonbolwell · 2023-01-13T03:29:35Z

@1kevgriff I had the same issue and was able to resolve by adding PackageSourceCredentials with a Personal Access Token created from Azure DevOps to the NuGet.config file under C:\Users\username\AppData\Roaming\NuGet

<configuration>
  <packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
    <add key="MyOrg" value="https://pkgs.dev.azure.com/xxxxxx/_packaging/MyOrg/nuget/v3/index.json" />
    <add key="Microsoft Visual Studio Offline Packages" value="C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\" />
  </packageSources>
 <packageSourceCredentials>
    <MyOrg>
        <add key="Username" value="... username here ...." />
        <add key="ClearTextPassword" value="... personal access token here ...." />
    </MyOrg>
</packageSourceCredentials>
</configuration>

Adding a PAT I got from here https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=Windows#create-a-pat

Hope that works for you as well

1kevgriff · 2023-01-13T19:09:12Z

This is my %appdata%/nuget/nuget.config file:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
    <add key="Microsoft Visual Studio Offline Packages" value="C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\" />
    <add key="My Org Name" value="https://nuget.pkg.github.com/MyOrgName/index.json" />
  </packageSources>
  <packageRestore>
    <add key="enabled" value="True" />
    <add key="automatic" value="True" />
  </packageRestore>
  <bindingRedirects>
    <add key="skip" value="False" />
  </bindingRedirects>
  <packageManagement>
    <add key="format" value="0" />
    <add key="disabled" value="False" />
  </packageManagement>
  <packageSourceCredentials>
    <MyOrgName>
        <add key="Username" value="(username)" />
        <add key="Password" value="(token) />
      </MyOrgName>
  </packageSourceCredentials>
</configuration>

It seems like I have everything where it is supposed to be, but VS building WorkerExtensions.csproj on the fly isn't using any of it.

1kevgriff · 2023-01-13T19:43:26Z

Also noticed this in the build output for the project:

24>C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\IDE\CommonExtensions\Microsoft\NuGet\NuGet.targets(132,5): warning : The plugin credential provider could not acquire credentials. Authentication may require manual action. Consider re-running the command with --interactive for `dotnet`, /p:NuGetInteractive="true" for MSBuild or removing the -NonInteractive switch for `NuGet`
24>C:\Users\kevin\AppData\Local\Temp\lgyvtjis.242\WorkerExtensions.csproj : error NU1301: Unable to load the service index for source https://nuget.pkg.github.com/MyOrgName/index.json.

jonbolwell · 2023-01-13T23:46:35Z

It definitely needed a change from Password to ClearTextPassword when I put the token in, it didn't work for me either using the key as just Password

1kevgriff · 2023-01-16T20:53:00Z

I need to review again, but moving %APPDATA% Nuget.Confg to ClearTextPassword didn't work.

fabiocav · 2023-01-18T19:46:10Z

Flagging this for investigations and ensure the following scenarios are handled:

Custom extension packages in private feeds only (WebJobs extensions)
Authenticated feeds
Environment with network restrictions limiting access to NuGet during restore only

fabiocav · 2023-01-18T19:48:12Z

@1kevgriff as a temporary workaround, moving your private feed entry from the global nuget.config file to a project level nuget.config would prevent the inner build from picking this up and potentially avoid this issue.

jviau · 2023-01-25T21:42:06Z

Linking this here so it is not lost: this comment also brings up another way in which the nuget restore on the inner build is problematic. Maybe we can address both issues at once.

DuckScapePhilip · 2023-05-10T19:40:21Z

@1kevgriff as a temporary workaround, moving your private feed entry from the global nuget.config file to a project level nuget.config would prevent the inner build from picking this up and potentially avoid this issue.

This worked for me. I had the Nuget.config in the solution folder, when I copied it into my azure functions project folder with build action set to NONE and Copy to Output Directory set to DO NOT COPY, it worked for me.

craigb · 2024-10-03T00:03:12Z

I'm running into this as well. In my case, I wrote a custom target to copy in the nuget.config from the restore step into the temp directory for the generated project:

<Project>
    <!-- Workaround for https://github.com/Azure/azure-functions-dotnet-worker/issues/1252 -->
    <!-- Target to copy the nuget.config from the root of the repo to the generated WorkerExtensions project. -->
    <!--   _GetRestoreSettings sets up @(_OutputConfigFilePaths) -->
    <!--   _FunctionsPostBuild sets up the $(ExtensionsCsProjFilePath) -->
    <!-- $(_OutputConfigFilePaths) *should* have the nuget.config file that should be used first, so we get the first with a simple regex -->
    <Target Name="CopyFirstNugetConfigToGeneratedDirectory" BeforeTargets="_WorkerExtensionsRestore" DependsOnTargets="_GetRestoreSettings;_FunctionsPostBuild">
        <PropertyGroup>
            <NugetConfig>$([System.Text.RegularExpressions.Regex]::Replace("$(_OutputConfigFilePaths)", ";.*$", "", "System.Text.RegularExpressions.RegexOptions.ECMAScript"))</NugetConfig>
        </PropertyGroup>
        <Copy SourceFiles="$(NugetConfig)" DestinationFolder="$(ExtensionsCsProjFilePath)" SkipUnchangedFiles="true" />
    </Target>
</Project>

jviau · 2024-10-04T17:18:00Z

I am actively working on this issue now. My current plan is to provide a mechanism to include the worker extension project as part of source control and let it be restored at the same time as the function app csproj it is for. This will allow it to inherit the same feed authentication as the function app.

Alternatively, the way to address it now is that however you authenticate in your restore step, make sure you provide the same authentication to your build step as well (as it will include the inner restore as well).

jviau · 2024-10-04T17:18:50Z

I can't seem to make my Azure Devops Pipeline work with SDK version 1.17.x (except for 1.17.2 which works). My pipeline:

stages:
  - stage: Build
    displayName: Build
    jobs:
      - job: Build
        displayName: Build
        pool:
          vmImage: ubuntu-latest
        steps:
          - task: NuGetAuthenticate@1
          - task: DotNetCoreCLI@2
            displayName: Restore packages
            inputs:
              command: "restore"
              projects: "**/*.csproj"
              feedsToUse: "config"
              nugetConfigPath: "$(Build.SourcesDirectory)/src/My.NameSpace.$(projectName)/nuget.config"
            env:
              TELERIK_API_KEY: $(telerikApiKey)
          - task: DotNetCoreCLI@2
            displayName: Build
            inputs:
              command: "build"
              projects: "**/*.csproj"
              arguments: "-c Release"

My nuget.config file:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <!--To inherit the global NuGet package sources remove the <clear/> line below -->
    <clear />
    <add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
    <add key="xxxxxxxxxxxx" value="https://xxxxxxxx.pkgs.visualstudio.com/_packaging/xxxxxxxx/nuget/v3/index.json" />
    <add key="Telerik NuGet Server" value="https://nuget.telerik.com/v3/index.json" />
  </packageSources>
  <packageSourceCredentials>
    <Telerik_x0020_NuGet_x0020_Server>
      <add key="Username" value="api-key" />
      <add key="ClearTextPassword" value="%TELERIK_API_KEY%" />
    </Telerik_x0020_NuGet_x0020_Server>
  </packageSourceCredentials>
</configuration>

The build process fails with 401 errors. I also tried task: UseDotNet@2 to install the 8.x .NET SDK. Also tried to install latest Nuget version. Any idea how to construct the pipeline to work?

Try including this in your build step also:

             env:
               TELERIK_API_KEY: $(telerikApiKey)

JakobWl · 2024-10-08T07:51:16Z

@jviau This wont fix the issue for this usecase:

            displayName: "[PRE] Authenticate to NuGet"
            inputs:
              nuGetServiceConnections: xxxx // some jfrog for example

          - task: DotNetCoreCLI@2
            displayName: "[PRE] Restore NuGet Packages"
            inputs:
              command: restore
              projects: "src/**/*.csproj"
              feedsToUse: config
              nugetConfigPath: "./nuget.config"
              externalFeedCredentials: xxx some jfrog for example

          Would you have a solution for this? I cannot seem to get it to work

jviau · 2024-10-08T16:32:22Z

@jakobwi I can't say for sure, but I imagine the externalFeedCredentials: <creds> either sets an environment variable or passes an arg to nuget restore. You may be able to inspect your build logs and then manually pass that value to the build command.

idg10 · 2024-10-10T18:00:35Z

Perhaps this is a daft question but why does the SDK even need to run its own private dotnet build here? That's a pretty unorthodox thing to do.

And as people have mentioned, it's problematic because it doesn't go through the normal routes. Unless you happen to run into this problem with private feeds, you would likely be entirely unaware that this extra package fetch was happening, and that's a real problem if you're trying to create an accurate SBOM to track what components you are using. (And that's a vital part of supply chain integrity.)

The DLL it builds seems to contain no code anyway. Why is this necessary? And could you find some way of doing it that doesn't operate outside the purview of tools designed to ensure supply chain integrity?

jviau · 2024-10-14T16:22:35Z

Perhaps this is a daft question but why does the SDK even need to run its own private dotnet build here? That's a pretty unorthodox thing to do.

And as people have mentioned, it's problematic because it doesn't go through the normal routes. Unless you happen to run into this problem with private feeds, you would likely be entirely unaware that this extra package fetch was happening, and that's a real problem if you're trying to create an accurate SBOM to track what components you are using. (And that's a vital part of supply chain integrity.)

The DLL it builds seems to contain no code anyway. Why is this necessary? And could you find some way of doing it that doesn't operate outside the purview of tools designed to ensure supply chain integrity?

This is necessary as part of constructing the webjobs extension payload that the host will load. When you use a worker extension, it declares what WebJobs extensions are associated with it (which are additional nuget packages). We do not know these packages until nuget restore is already complete and we need to combine multiple extensions together and consolidate dependencies. This necessitates an inner build which will fetch and process these packages. We have discussed this with the nuget, dotnet, and msbuild team and there is no alternative for us.

As far as SBOM goes, you should be running that on your final output contents. Everything this process uses in the end is part of your projects output directory in the .azurefunctions sub folder. Additionally, the project.assets.json of this inner build is available (in your intermediate output folder) for tooling to scan.

jdinardofsl · 2024-10-17T14:16:46Z

Any update on this? I was running into the same issue with Microsoft.Azure.Functions.Worker.Sdk" Version="1.18.1. Builds succeeded locally but would fail in the ADO pipeline. This was incredibly frustrating and I spent hours trying to understand why this was happening before coming across this article and ultimately downgrading back to version 1.17.2. My organization enforces the use of a private nuget feed, so adding nuget.org to our list of sources to the pipeline is not acceptable even if it does fix the issue.

lovelangy · 2024-10-31T00:28:36Z

Any update on this? I was running into the same issue with Microsoft.Azure.Functions.Worker.Sdk" Version="1.18.1. Builds succeeded locally but would fail in the ADO pipeline. This was incredibly frustrating and I spent hours trying to understand why this was happening before coming across this article and ultimately downgrading back to version 1.17.2. My organization enforces the use of a private nuget feed, so adding nuget.org to our list of sources to the pipeline is not acceptable even if it does fix the issue.

@jdinardofsl thanks. I had the same issue. Downgrading back to version 1.17.2 works.

Liero · 2024-11-05T10:09:25Z

I too have the problem. Obviously it is a bug, so please threat is as one!

This simple pipeline will fail on ubuntu-20.04:

name: 'Build Solution'
description: 'Build .NET solution'
inputs:
  VS_PAT:
    description: 'The PAT token for the feed'
    required: true

runs:
  using: 'composite'
  steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Setup .NET
        uses: actions/setup-dotnet@v2
        with:
          dotnet-version: '8.x'

      - name: Restore dependencies
        run: dotnet restore --configfile NuGet.Config
        shell: bash

      - name: Build
        run: dotnet build --no-restore --configuration Release
        shell: bash

NuGet.config

<?xml version="1.0" encoding="utf-8"?>
<configuration>
	<packageSources>
		<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
		<add key="MyPrivateFeed" value="https://mycompany.pkgs.visualstudio.com/MySolution/_packaging/MyPrivateFeed/nuget/v3/index.json" />
	</packageSources>
	<packageSourceCredentials>
		<MyPrivateFeed>
			<add key="Username" value="XXX" />
			<add key="ClearTextPassword" value="{PAT}" />
		</MyPrivateFeed>		
</configuration>

Liero · 2024-11-05T10:37:42Z

We do not know these packages until nuget restore is already complete and we need to combine multiple extensions together and consolidate dependencies

Could you do it as part of dotnet restore? Just use more appropriate msbuild target.

jviau · 2024-11-05T17:09:45Z

Could you do it as part of dotnet restore? Just use more appropriate msbuild target.

We would love to, but unfortunately there are many things which prevent that from being feasible.

It's a chicken and egg problem: our targets which would do this work won't exist until restore itself runs.
Restore is special and not extensible like traditional msbuild targets. We can't even hook into it from a project perspective even if our targets were available at that time.
We rely on compile time to calculate what WebJobs extensions are needed anyways
- This is combination of scanning referenced assemblies and seeing if you even use the extensions in the first place. If you reference ServiceBus but never use any service bus triggers or bindings, we will not bother including that extension.

petrkasnal · 2024-11-12T06:42:12Z

So is there a solution here, please? I upgraded Azure Function to the new version I need for Aspire and it returns the error described here. It's really awkward,because I can't use Aspire without the upgrade. Please help. Thanks

Pipeline

- task: DotNetCoreCLI@2
  displayName: Nuget restore
  inputs:
    command: 'restore'
    projects: '${{ parameters.solution }}'
    feedsToUse: 'config'
    nugetConfigPath: 'NuGet.config'
    includeNuGetOrg: true

- task: DotNetCoreCLI@2
  displayName: Build
  inputs:
    command: 'build'
    projects: ${{ parameters.projects }}
    arguments: '--no-restore --configuration ${{ parameters.buildConfiguration }} /p:Version=100.4'
    versioningScheme: byBuildNumber

Log

Determining projects to restore...
Failed to download package 'Microsoft.NETCore.Targets.3.0.0' from 'https://pkgs.dev.azure.com/mypckg/f433b8a7-a701-48e9-b916-e4ac90fa6b4b/_packaging/af41060d-f5f5-4667-8078-42f88f984727/nuget/v3/flat2/microsoft.netcore.targets/3.0.0/microsoft.netcore.targets.3.0.0.nupkg'.
Response status code does not indicate success: 401 (Unauthorized).
Retrying 'FindPackagesByIdAsync' for source 'https://pkgs.dev.azure.com/mypckg/f433b8a7-a701-48e9-b916-e4ac90fa6b4b/_packaging/036f3e9a-7104-43cd-bed3-406a8f5ec881/nuget/v3/flat2/microsoft.netcore.targets/index.json'.
Response status code does not indicate success: 401 (Unauthorized).
Retrying 'FindPackagesByIdAsync' for source 'https://pkgs.dev.azure.com/mypckg/f433b8a7-a701-48e9-b916-e4ac90fa6b4b/_packaging/af41060d-f5f5-4667-8078-42f88f984727/nuget/v3/flat2/microsoft.net.sdk.functions/index.json'.
Response status code does not indicate success: 401 (Unauthorized).
Retrying 'FindPackagesByIdAsync' for source 'https://pkgs.dev.azure.com/mypckg/f433b8a7-a701-48e9-b916-e4ac90fa6b4b/_packaging/036f3e9a-7104-43cd-bed3-406a8f5ec881/nuget/v3/flat2/microsoft.net.sdk.functions/index.json'.
Response status code does not indicate success: 401 (Unauthorized).
Retrying 'FindPackagesByIdAsync' for source 'https://pkgs.dev.azure.com/mypckg/f433b8a7-a701-48e9-b916-e4ac90fa6b4b/_packaging/036f3e9a-7104-43cd-bed3-406a8f5ec881/nuget/v3/flat2/microsoft.azure.webjobs.extensions.servicebus/index.json'.
Response status code does not indicate success: 401 (Unauthorized).
Retrying 'FindPackagesByIdAsync' for source 'https://pkgs.dev.azure.com/mypckg/f433b8a7-a701-48e9-b916-e4ac90fa6b4b/_packaging/036f3e9a-7104-43cd-bed3-406a8f5ec881/nuget/v3/flat2/microsoft.netcore.targets/index.json'.
Response status code does not indicate success: 401 (Unauthorized).
Failed to download package 'Microsoft.NETCore.Targets.3.0.0' from 'https://pkgs.dev.azure.com/mypckg/f433b8a7-a701-48e9-b916-e4ac90fa6b4b/_packaging/af41060d-f5f5-4667-8078-42f88f984727/nuget/v3/flat2/microsoft.netcore.targets/3.0.0/microsoft.netcore.targets.3.0.0.nupkg'.
Response status code does not indicate success: 401 (Unauthorized).
Retrying 'FindPackagesByIdAsync' for source 'https://pkgs.dev.azure.com/mypckg/f433b8a7-a701-48e9-b916-e4ac90fa6b4b/_packaging/af41060d-f5f5-4667-8078-42f88f984727/nuget/v3/flat2/microsoft.net.sdk.functions/index.json'.
Response status code does not indicate success: 401 (Unauthorized).
Retrying 'FindPackagesByIdAsync' for source 'https://pkgs.dev.azure.com/mypckg/f433b8a7-a701-48e9-b916-e4ac90fa6b4b/_packaging/036f3e9a-7104-43cd-bed3-406a8f5ec881/nuget/v3/flat2/microsoft.azure.webjobs.extensions.servicebus/index.json'.
Response status code does not indicate success: 401 (Unauthorized).
Retrying 'FindPackagesByIdAsync' for source 'https://pkgs.dev.azure.com/mypckg/f433b8a7-a701-48e9-b916-e4ac90fa6b4b/_packaging/036f3e9a-7104-43cd-bed3-406a8f5ec881/nuget/v3/flat2/microsoft.net.sdk.functions/index.json'.

##[error]Src/FunctionApp/obj/Release/net8.0/WorkerExtensions/WorkerExtensions.csproj(0,0): Error NU1301: Failed to retrieve information about 'Microsoft.NET.Sdk.Functions' from remote source 'https://pkgs.dev.azure.com/mypckg/f433b8a7-a701-48e9-b916-e4ac90fa6b4b/_packaging/036f3e9a-7104-43cd-bed3-406a8f5ec881/nuget/v3/flat2/microsoft.net.sdk.functions/index.json'.
/home/vsts/work/1/s/Src/FunctionApp/obj/Release/net8.0/WorkerExtensions/WorkerExtensions.csproj : error NU1301: Failed to retrieve information about 'Microsoft.NET.Sdk.Functions' from remote source 'https://pkgs.dev.azure.com/mypckg/f433b8a7-a701-48e9-b916-e4ac90fa6b4b/_packaging/036f3e9a-7104-43cd-bed3-406a8f5ec881/nuget/v3/flat2/microsoft.net.sdk.functions/index.json'.
##[error]Src/FunctionApp/obj/Release/net8.0/WorkerExtensions/WorkerExtensions.csproj(0,0): Error NU1301: Failed to retrieve information about 'Microsoft.NET.Sdk.Functions' from remote source 'https://pkgs.dev.azure.com/mypckg/f433b8a7-a701-48e9-b916-e4ac90fa6b4b/_packaging/036f3e9a-7104-43cd-bed3-406a8f5ec881/nuget/v3/flat2/microsoft.net.sdk.functions/index.json'.
/home/vsts/work/1/s/Src/FunctionApp/obj/Release/net8.0/WorkerExtensions/WorkerExtensions.csproj : error NU1301: Failed to retrieve information about 'Microsoft.NET.Sdk.Functions' from remote source 'https://pkgs.dev.azure.com/mypckg/f433b8a7-a701-48e9-b916-e4ac90fa6b4b/_packaging/036f3e9a-7104-43cd-bed3-406a8f5ec881/nuget/v3/flat2/microsoft.net.sdk.functions/index.json'.
##[error]Src/FunctionApp/obj/Release/net8.0/WorkerExtensions/WorkerExtensions.csproj(0,0): Error NU1301: Failed to retrieve information about 'Microsoft.NETCore.Targets' from remote source 'https://pkgs.dev.azure.com/mypckg/f433b8a7-a701-48e9-b916-e4ac90fa6b4b/_packaging/036f3e9a-7104-43cd-bed3-406a8f5ec881/nuget/v3/flat2/microsoft.netcore.targets/index.json'.
/home/vsts/work/1/s/Src/FunctionApp/obj/Release/net8.0/WorkerExtensions/WorkerExtensions.csproj : error NU1301: Failed to retrieve information about 'Microsoft.NETCore.Targets' from remote source 'https://pkgs.dev.azure.com/mypckg/f433b8a7-a701-48e9-b916-e4ac90fa6b4b/_packaging/036f3e9a-7104-43cd-bed3-406a8f5ec881/nuget/v3/flat2/microsoft.netcore.targets/index.json'.
##[error]Src/FunctionApp/obj/Release/net8.0/WorkerExtensions/WorkerExtensions.csproj(0,0): Error NU1301: Failed to retrieve information about 'Microsoft.NETCore.Targets' from remote source 'https://pkgs.dev.azure.com/mypckg/f433b8a7-a701-48e9-b916-e4ac90fa6b4b/_packaging/036f3e9a-7104-43cd-bed3-406a8f5ec881/nuget/v3/flat2/microsoft.netcore.targets/index.json'.
/home/vsts/work/1/s/Src/FunctionApp/obj/Release/net8.0/WorkerExtensions/WorkerExtensions.csproj : error NU1301: Failed to retrieve information about 'Microsoft.NETCore.Targets' from remote source 'https://pkgs.dev.azure.com/mypckg/f433b8a7-a701-48e9-b916-e4ac90fa6b4b/_packaging/036f3e9a-7104-43cd-bed3-406a8f5ec881/nuget/v3/flat2/microsoft.netcore.targets/index.json'.
##[error]/usr/share/dotnet/sdk/8.0.403/NuGet.targets(174,5): Error : Failed to download package 'Microsoft.NETCore.Targets.3.0.0' from 'https://pkgs.dev.azure.com/mypckg/f433b8a7-a701-48e9-b916-e4ac90fa6b4b/_packaging/af41060d-f5f5-4667-8078-42f88f984727/nuget/v3/flat2/microsoft.netcore.targets/3.0.0/microsoft.netcore.targets.3.0.0.nupkg'.
Response status code does not indicate success: 401 (Unauthorized).

Dahlorna · 2024-11-15T06:46:02Z

@jviau
Do you happen to know why this temporary project (WorkerExtensions.csproj) is still targeting net6.0 framework (EOL'ed recently)? With private feed this is very cumbersome to maintain if you have switched to use net8.0 as you will need some packages from net6.0 target.

For example:
Update your pipelines to use SDK 8.0.403
build project that uses Microsoft.Azure.Functions.Worker.Sdk 1.81.1
you get error "Unable to find package Microsoft.NETCore.App.Ref with version (=6.0.35)" as no-one has added that to private feed as you are using net8.0!
Eventually you will need to add following packages to your private feed to build your project successfully

Microsoft.NETCore.App.Ref 6.0.35
Microsoft.AspNetCore.App.Ref 6.0.35
Microsoft.WindowsDesktop.App.Ref 6.0.35

We rely on compile time to calculate what WebJobs extensions are needed anyways

This is combination of scanning referenced assemblies and seeing if you even use the extensions in the first place. If you reference ServiceBus but never use any service bus triggers or bindings, we will not bother including that extension.

Would you be able to determinate the correct targeting version and add the same as target in yours temporary project (WorkerExtensions.csproj) ? Would help a lot, as those ref packages comes with used .net sdk...

robmaas · 2024-11-21T09:14:21Z

More issues with WorkerExtensions.csproj:

Reference to MessagePack 1.9.11, which has an active vulnerability. This triggers vulnerability warnings in msbuild, thus blocking us from introducing new functionality. There is no way to patch this ourselves. That project should target net8 or net9.
--no-incremental builds are still broken since 1.17.3: Version 1.17.0 breaks solution builds using no-incremental #2284

elamani8 · 2024-11-25T16:22:31Z

I could make it work with a workaround, the idea is to continue on the first build, then add a script that :
1 - Remove the private feed with dotnet nuget remove source NAME_OF_THE_SOURCE
2- Build WorkerExtensions.csproj
3- Add private feed dotnet nuget add source PRIVATE_FEED_URL -n NAME_OF_THE_SOURCE
4- Rebuild solution

    - task: PowerShell@2
      displayName: Dotnet first build 
      continueOnError: true # sontinue if error
      inputs:
        targetType: 'inline'
        script: |
          dotnet build --configuration ${{ parameters.buildConfiguration }} --no-restore
        workingDirectory: '$(Build.SourcesDirectory)/$(Build.Repository.Name)/Source'  # .sln path

    - task: PowerShell@2
      displayName: Dotnet 2nd build 
      condition: failed()
      inputs:
        targetType: 'inline'
        script: |
          dotnet nuget list source
          dotnet nuget remove source NAME_OF_THE_SOURCE
          dotnet nuget list source
          dotnet build ./YOUR_FOLDER/obj/Release/net8.0/WorkerExtensions/WorkerExtensions.csproj --configuration release
          dotnet nuget add source PRIVATE_FEED_URL  -n  NAME_OF_THE_SOURCE
          dotnet nuget list source
          dotnet build --configuration release --no-restore
        workingDirectory: '$(Build.SourcesDirectory)/$(Build.Repository.Name)/Source'  # .sln path

ch53k · 2024-12-08T19:38:57Z

I have 2 function applications 1 that run with the DurableTask 1.2.2 package included and 1 without. The application withOUT the Durable Task library builds fine with Microsoft.Azure.Functions.Worker.Sdk 1.18.1, but if I include the DurableTask package, then the csproj file gets generated. This results in failed ADO builds because we use a private Nuget feed that fails to restore.

Downgrading the SDK package to 1.17.2 allows the build to succeed as @lovelangy stated.

Here are my working and not working csproj files.

WORKING:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
	  <AzureFunctionsVersion>v4</AzureFunctionsVersion>
	  <OutputType>Exe</OutputType>
	  <LangVersion>latest</LangVersion>
	  <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>
  <ItemGroup>
	  <FrameworkReference Include="Microsoft.AspNetCore.App" />
	  <PackageReference Include="Microsoft.ApplicationInsights" Version="2.22.0" />
	  <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
	  <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.23.0" />
	  <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues" Version="5.5.0" />
	  <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Timer" Version="4.3.1" />
	  <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Warmup" Version="4.0.2" />
	  <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.2.0" />
	  <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.18.1" />
	  <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" />
    <PackageReference Include="Serilog.Sinks.ApplicationInsights" Version="4.0.0" />
    <PackageReference Include="Microsoft.Extensions.Configuration.AzureAppConfiguration" Version="8.0.0" />
    <PackageReference Include="System.Data.SqlClient" Version="4.9.0" />
    <PackageReference Include="System.Text.Json" Version="8.0.5" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
    <ItemGroup>
        <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext" />
    </ItemGroup>
</Project>

DOES NOT WORK (the only difference is the inclusion of the DurableTask package)

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
	  <AzureFunctionsVersion>v4</AzureFunctionsVersion>
	  <OutputType>Exe</OutputType>
	  <LangVersion>latest</LangVersion>
	  <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>
  <ItemGroup>
	  <FrameworkReference Include="Microsoft.AspNetCore.App" />
	  <PackageReference Include="Microsoft.ApplicationInsights" Version="2.22.0" />
	  <PackageReference Include="Microsoft.ApplicationInsights.WorkerService" Version="2.22.0" />
	  <PackageReference Include="Microsoft.Azure.Functions.Worker" Version="1.23.0" />
	  <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.DurableTask" Version="1.2.2" />
	  <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Storage.Queues" Version="5.5.0" />
	  <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Timer" Version="4.3.1" />
	  <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Warmup" Version="4.0.2" />
	  <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http" Version="3.2.0" />
	  <PackageReference Include="Microsoft.Azure.Functions.Worker.Sdk" Version="1.18.1" />
	  <PackageReference Include="Microsoft.Azure.Functions.Worker.Extensions.Http.AspNetCore" Version="1.2.1" />
    <PackageReference Include="Serilog.Sinks.ApplicationInsights" Version="4.0.0" />
    <PackageReference Include="Microsoft.Extensions.Configuration.AzureAppConfiguration" Version="8.0.0" />
    <PackageReference Include="System.Data.SqlClient" Version="4.9.0" />
    <PackageReference Include="System.Text.Json" Version="8.0.5" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
  </ItemGroup>
    <ItemGroup>
        <Using Include="System.Threading.ExecutionContext" Alias="ExecutionContext" />
    </ItemGroup>
</Project>

campelo · 2024-12-14T00:05:03Z

I'm facing the same issue.

When using .NET 9 with "Microsoft.Azure.Functions.Worker.Sdk" Version="2.0.0" I have the same error.

/obj/Debug/net9.0/WorkerExtensions/WorkerExtensions.csproj(0,0): Error NU1301: Unable to load the service index for source http://my-private-repo

When using .NET 8 with "Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" everything works as expected.

It's not possible to use .NET 9 with "Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" because of Invalid combination of TargetFramework and AzureFunctionsVersion is set. error in build time.

It will be appreciated if a fix is available soon. Thanks.

## Summary of changes Attempt to fix flakiness in Azure Functions multi-sample build ## Reason for change #6472 added multi-version building for Azure Functions samples. Unfortunately, this caused the build stage to be flaky, because Azure Functions apparently generates and builds a [completely separate _.csproj_](Azure/azure-functions-dotnet-worker#1252). Unfortunately, it also ignores all the artifact output stuff, which means when we restore/build multiple versions of the app (with different api versions, it stomps over itself. e.g. we can see the sample app build itself doing the right thing: ``` 08:59:05 [DBG] Samples.AzureFunctions.V4Isolated -> /project/artifacts/bin/Samples.AzureFunctions.V4Isolated/release_net6.0_1.6.0/Samples.AzureFunctions.V4Isolated.dll 08:59:06 [DBG] Samples.AzureFunctions.V4Isolated -> /project/artifacts/publish/Samples.AzureFunctions.V4Isolated/release_net6.0_1.6.0/ ``` But there's also the "WorkerExtensions" thing which is going completely off the rails, ignores all of the Directory.Build.props etc and just does its own thing ``` 08:59:07 [DBG] WorkerExtensions -> /tmp/oh4iajvh.kcj/publishout/ 08:59:07 [DBG] WorkerExtensions -> /tmp/zv30zzl2.cxz/publishout/Microsoft.Azure.Functions.Worker.Extensions.dll 08:59:08 [DBG] WorkerExtensions -> /tmp/zv30zzl2.cxz/publishout/ ``` Unfortunately, this shows it's trying to build two separate versions to the same location, and things break. ## Implementation details My initial attempt in #6521 failed. In this attempt I split the v1 SDK and v2 SDK into two separate projects. The SDK versions are tracked separately. I was thinking that as long as we only build a _single_ version per project we _should_ be ok. It was not OK. So in the end I tore out the Azure Functions version tracking. We could/should consider adding it back in some way, but right now this is causing too many issues An alternative is to just remove the Azure Functions samples from the "auto-updating multi version". I kept the split between v1 and v2 of the Azure Functions SDK to give us a _little_ more coverage; I think it's about the best we can do. ## Test coverage If this all finally passes, we should be good. ## Other details An important thing to note is that _currently_, even though we will now get dependabot notifactions about updates to the azure functions libs, these _aren't_ tested automatically. That's because currently our testing on Windows does _not_ run the "multi version" tests like we do on Linux. And we _only_ test Azure functions on Windows. This is something I'd like to address longer term with PRs like #6498, but for the meantime, we'll need to manually keep the samples up to date with the latest SDK version when there's a dependabot PR

sunnynagavo · 2025-01-14T17:54:28Z

Any update on this? I was running into the same issue with Microsoft.Azure.Functions.Worker.Sdk" Version="1.18.1. Builds succeeded locally but would fail in the ADO pipeline. This was incredibly frustrating and I spent hours trying to understand why this was happening before coming across this article and ultimately downgrading back to version 1.17.2. My organization enforces the use of a private nuget feed, so adding nuget.org to our list of sources to the pipeline is not acceptable even if it does fix the issue.

@jdinardofsl thanks. I had the same issue. Downgrading back to version 1.17.2 works.

We are using <PackageReference Update="Microsoft.Azure.Functions.Worker.Sdk" Version="[1.17.2]" /> in our project and still it tries to download nugets from public repo which is now restricted for our team.

Error details: C:\Users\ContainerAdministrator\AppData\Local\Temp\mrnjchtq.emz\WorkerExtensions.csproj : error NU1301: Unable to load the service index for source https://api.nuget.org/v3/index.json.

sunnynagavo · 2025-01-15T17:47:37Z

I'm facing the same issue.

When using .NET 9 with "Microsoft.Azure.Functions.Worker.Sdk" Version="2.0.0" I have the same error.
/obj/Debug/net9.0/WorkerExtensions/WorkerExtensions.csproj(0,0): Error NU1301: Unable to load the service index for source http://my-private-repo
When using .NET 8 with "Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" everything works as expected.

It's not possible to use .NET 9 with "Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" because of Invalid combination of TargetFramework and AzureFunctionsVersion is set. error in build time.

It will be appreciated if a fix is available soon. Thanks.

Hi @campelo,

Are you sure it worked for you ? we are also using .NET 8 with "Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" but still hitting same issue in our pipeline.

C:\Users\ContainerAdministrator\AppData\Local\Temp\mrnjchtq.emz\WorkerExtensions.csproj : error NU1301: Unable to load the service index for source https://api.nuget.org/v3/index.json.

jviau · 2025-01-15T17:51:39Z

Any update on this? I was running into the same issue with Microsoft.Azure.Functions.Worker.Sdk" Version="1.18.1. Builds succeeded locally but would fail in the ADO pipeline. This was incredibly frustrating and I spent hours trying to understand why this was happening before coming across this article and ultimately downgrading back to version 1.17.2. My organization enforces the use of a private nuget feed, so adding nuget.org to our list of sources to the pipeline is not acceptable even if it does fix the issue.

@jdinardofsl thanks. I had the same issue. Downgrading back to version 1.17.2 works.

We are using <PackageReference Update="Microsoft.Azure.Functions.Worker.Sdk" Version="[1.17.2]" /> in our project and still it tries to download nugets from public repo which is now restricted for our team.

Error details: C:\Users\ContainerAdministrator\AppData\Local\Temp\mrnjchtq.emz\WorkerExtensions.csproj : error NU1301: Unable to load the service index for source https://api.nuget.org/v3/index.json.

@sunnynagavo this is what the latest package versions aim to solve: they will respect your nuget.config and no longer only use nuget.org. But if your nuget.config points to authenticated feeds, you will need to ensure you are authenticated to them before building your function app.

tbuquet · 2025-01-15T18:08:03Z

@jviau
Do you happen to know why this temporary project (WorkerExtensions.csproj) is still targeting net6.0 framework (EOL'ed recently)? With private feed this is very cumbersome to maintain if you have switched to use net8.0 as you will need some packages from net6.0 target.

I would also love to know why, I have a custom trigger with references to net8.0 packages that I cannot update because WorkerExtensions.csproj is still targetting net6.0, even though the in-process model is supposed to be out for net8.0 now...

Can we expect an update on that?

jviau · 2025-01-15T18:22:55Z

I have a custom trigger with references to net8.0 packages that I cannot update because WorkerExtensions.csproj is still targetting net6.0

Can you explain how this is blocking? If you are referring to Microsoft.Extensions.*/8.x packages, these do not require net8.0. You can target them from net6.0 just fine.

The reason we have not updated WorkerExtensions.csproj to net8 is that it is not crucial at the moment: this project is only for package resolution & unification. The net6 runtime is not actually used outside of compilation. The runtime is determined by the function host, which is net8.

I have opened an issue #2924 to explore updating to net8, which will be a better place to discuss that than this issue.

campelo · 2025-01-16T12:44:15Z

I'm facing the same issue.

When using .NET 9 with "Microsoft.Azure.Functions.Worker.Sdk" Version="2.0.0" I have the same error.
/obj/Debug/net9.0/WorkerExtensions/WorkerExtensions.csproj(0,0): Error NU1301: Unable to load the service index for source http://my-private-repo
When using .NET 8 with "Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" everything works as expected.

It's not possible to use .NET 9 with "Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" because of Invalid combination of TargetFramework and AzureFunctionsVersion is set. error in build time.

It will be appreciated if a fix is available soon. Thanks.
Hi @campelo,

Are you sure it worked for you ? we are also using .NET 8 with "Microsoft.Azure.Functions.Worker.Sdk" Version="1.17.2" but still hitting same issue in our pipeline.

C:\Users\ContainerAdministrator\AppData\Local\Temp\mrnjchtq.emz\WorkerExtensions.csproj : error NU1301: Unable to load the service index for source https://api.nuget.org/v3/index.json.

Yes, everything works. Our application is in production using .NET 8 since it was released. We are facing the error when using .NET 9.

ghost added the Needs: Triage (Functions) label Dec 30, 2022

ghost assigned jviau Dec 30, 2022

kshyju added Needs: Author Feedback and removed Needs: Triage (Functions) labels Jan 5, 2023

ghost added the no-recent-activity label Jan 9, 2023

ghost added Needs: Attention 👋 and removed Needs: Author Feedback no-recent-activity labels Jan 9, 2023

fabiocav added Needs: Author Feedback and removed Needs: Attention 👋 labels Jan 11, 2023

ghost added Needs: Attention 👋 and removed Needs: Author Feedback labels Jan 12, 2023

fabiocav added needs-investigation and removed Needs: Attention 👋 labels Jan 18, 2023

fabiocav unassigned jviau Jan 18, 2023

jviau linked a pull request Oct 9, 2024 that will close this issue

Add support for externally supplied worker extensions project #2763

Open

7 tasks

This comment has been minimized.

Sign in to view

jviau self-assigned this Dec 4, 2024

This was referenced Jan 9, 2025

Attempt to fix flakiness in Azure Functions multi-sample build DataDog/dd-trace-dotnet#6521

Closed

Fix flakiness in Azure Functions DataDog/dd-trace-dotnet#6524

Merged

WorkerExtensions.csproj trying to restore from private nuget feed, unsuccessfully #1252

WorkerExtensions.csproj trying to restore from private nuget feed, unsuccessfully #1252

Comments

1kevgriff commented Dec 30, 2022

kshyju commented Jan 5, 2023

ghost commented Jan 9, 2023

1kevgriff commented Jan 9, 2023

jviau commented Jan 9, 2023

madhavireddythirumuru commented Jan 10, 2023 • edited Loading

1kevgriff commented Jan 12, 2023 • edited Loading

jonbolwell commented Jan 13, 2023 • edited Loading

1kevgriff commented Jan 13, 2023 • edited Loading

1kevgriff commented Jan 13, 2023

jonbolwell commented Jan 13, 2023 • edited Loading

1kevgriff commented Jan 16, 2023

fabiocav commented Jan 18, 2023

fabiocav commented Jan 18, 2023

jviau commented Jan 25, 2023

DuckScapePhilip commented May 10, 2023

craigb commented Oct 3, 2024

jviau commented Oct 4, 2024

jviau commented Oct 4, 2024

JakobWl commented Oct 8, 2024 • edited Loading

jviau commented Oct 8, 2024

idg10 commented Oct 10, 2024

jviau commented Oct 14, 2024 • edited Loading

jdinardofsl commented Oct 17, 2024

lovelangy commented Oct 31, 2024

Liero commented Nov 5, 2024

Liero commented Nov 5, 2024

This comment has been minimized.

jviau commented Nov 5, 2024

petrkasnal commented Nov 12, 2024

Dahlorna commented Nov 15, 2024

robmaas commented Nov 21, 2024 • edited Loading

elamani8 commented Nov 25, 2024 • edited Loading

ch53k commented Dec 8, 2024

campelo commented Dec 14, 2024

sunnynagavo commented Jan 14, 2025 • edited Loading

sunnynagavo commented Jan 15, 2025 • edited Loading

jviau commented Jan 15, 2025

tbuquet commented Jan 15, 2025

jviau commented Jan 15, 2025 • edited Loading

campelo commented Jan 16, 2025

madhavireddythirumuru commented Jan 10, 2023 •

edited

Loading

1kevgriff commented Jan 12, 2023 •

edited

Loading

jonbolwell commented Jan 13, 2023 •

edited

Loading

1kevgriff commented Jan 13, 2023 •

edited

Loading

jonbolwell commented Jan 13, 2023 •

edited

Loading

JakobWl commented Oct 8, 2024 •

edited

Loading

jviau commented Oct 14, 2024 •

edited

Loading

robmaas commented Nov 21, 2024 •

edited

Loading

elamani8 commented Nov 25, 2024 •

edited

Loading

sunnynagavo commented Jan 14, 2025 •

edited

Loading

sunnynagavo commented Jan 15, 2025 •

edited

Loading

jviau commented Jan 15, 2025 •

edited

Loading