We've got an Azure classic pipeline (not yaml) that builds a solution with a mix of net core and traditional net projects. It has several steps and it looks something like this:

Some of the projects require components hosted on our custom Nuget feed and we're using a nuget.config which is passed to the dotnet restore task (and also to the Nuget restore task). It looks something like this:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <packageSources>
        <add key="nuget" value="/" />
        <add key="Pagesp" value="https://our_custom_feed_repository" />
    </packageSources>
</configuration>

The pipeline stopped working on the dotnet publish step. The yaml for this step looks something like this:

#Your build pipeline references an undefined variable named ‘BuildConfiguration’. Create or edit the build pipeline for this YAML file, define the variable on the Variables tab. See /?linkid=865972

steps:
- task: DotNetCoreCLI@2
  displayName: 'dotnet publish '
  inputs:
    command: publish
    publishWebProjects: false
    projects: |
     ./project1.csproj
     ./project2.csproj
    arguments: '-c $(BuildConfiguration) -o $(Build.ArtifactStagingDirectory) --self-contained -r win-x64'
    verbosityRestore: Detailed
    verbosityPack: Detailed

The logs show that dotnet publish is trying to Microsoft.NETCore.App.Runtime.win-x64 from our Nuget feed instead of getting it from the official one:

025-02-05T16:56:40.0184221Z   Retrying 'FindPackagesByIdAsyncCore' for source 'https://our_custom_feed_repository/nuget/FindPackagesById()?id='Microsoft.NETCore.App.Runtime.win-x64'&semVerLevel=2.0.0'.
2025-02-05T16:56:40.0189364Z   Response status code does not indicate success: 401 (Unauthorized).

Any clue on what's going on?

EDIT: I've also tried using the --no-restore option with the dotnet publish command as suggested in the answer below. However, that doesn't work because the previous builds didn't target the win-x64 platform:

 error NETSDK1047: Assets file 'D:\a\1\s\Sra.Assistencias.Rest\obj\project.assets.json' doesn't have a target for 'net9.0/win-x64'. Ensure that restore has run and that you have included 'net9.0' in the TargetFrameworks for your project. You may also need to include 'win-x64' in your project's RuntimeIdentifiers. [D:\a\1\s\Sra.Assistencias.Rest\Sra.Assistencias.Rest.csproj]

I've also tried adding a dotnet build task (before the dotnet publish task) but whenever it's configured to use the --self-contained -r win-x64 option, it will always try to get the required NuGet packages from our custom feed (which ends up with a 401 because these tasks don't allow us to pass the required credentials for checking that feed source).

I really don't want to add the runtime target to my csproj because that would mean changing it in several project files when we move to Linux (instead of just changing the options for the dotnet publish task of our pipeline). This pipeline was working okay (the last successful publish was on the 11th of October 2023), though at the time it was using net 7.0...

EDIT2: I've already tried adding the runtime identifier to the server web apps (which host Blazor wasm app) and now those projects to build. However, the others that are shared between the WASM Blazor app web app still fail with the same error.

EDIT3: Just to add that the equivalent command (dotnet publish SRA.Assistencias.Rest.csproj -o $destination --self-contained -r win-x64 runs without any issues from a Windows 11 pro machine).

EDIT4: Just to add that removing the self-contained option fixes the issue (ie, publishing/building in a framework-dependent manner does not result in any build error).

Thanks.

We've got an Azure classic pipeline (not yaml) that builds a solution with a mix of net core and traditional net projects. It has several steps and it looks something like this:

Some of the projects require components hosted on our custom Nuget feed and we're using a nuget.config which is passed to the dotnet restore task (and also to the Nuget restore task). It looks something like this:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <packageSources>
        <add key="nuget.org" value="https://www.nuget.org/api/v2/" />
        <add key="Pagesp" value="https://our_custom_feed_repository" />
    </packageSources>
</configuration>

The pipeline stopped working on the dotnet publish step. The yaml for this step looks something like this:

#Your build pipeline references an undefined variable named ‘BuildConfiguration’. Create or edit the build pipeline for this YAML file, define the variable on the Variables tab. See https://go.microsoft.com/fwlink/?linkid=865972

steps:
- task: DotNetCoreCLI@2
  displayName: 'dotnet publish '
  inputs:
    command: publish
    publishWebProjects: false
    projects: |
     ./project1.csproj
     ./project2.csproj
    arguments: '-c $(BuildConfiguration) -o $(Build.ArtifactStagingDirectory) --self-contained -r win-x64'
    verbosityRestore: Detailed
    verbosityPack: Detailed

The logs show that dotnet publish is trying to Microsoft.NETCore.App.Runtime.win-x64 from our Nuget feed instead of getting it from the official one:

025-02-05T16:56:40.0184221Z   Retrying 'FindPackagesByIdAsyncCore' for source 'https://our_custom_feed_repository/nuget/FindPackagesById()?id='Microsoft.NETCore.App.Runtime.win-x64'&semVerLevel=2.0.0'.
2025-02-05T16:56:40.0189364Z   Response status code does not indicate success: 401 (Unauthorized).

Any clue on what's going on?

EDIT: I've also tried using the --no-restore option with the dotnet publish command as suggested in the answer below. However, that doesn't work because the previous builds didn't target the win-x64 platform:

 error NETSDK1047: Assets file 'D:\a\1\s\Sra.Assistencias.Rest\obj\project.assets.json' doesn't have a target for 'net9.0/win-x64'. Ensure that restore has run and that you have included 'net9.0' in the TargetFrameworks for your project. You may also need to include 'win-x64' in your project's RuntimeIdentifiers. [D:\a\1\s\Sra.Assistencias.Rest\Sra.Assistencias.Rest.csproj]

I've also tried adding a dotnet build task (before the dotnet publish task) but whenever it's configured to use the --self-contained -r win-x64 option, it will always try to get the required NuGet packages from our custom feed (which ends up with a 401 because these tasks don't allow us to pass the required credentials for checking that feed source).

I really don't want to add the runtime target to my csproj because that would mean changing it in several project files when we move to Linux (instead of just changing the options for the dotnet publish task of our pipeline). This pipeline was working okay (the last successful publish was on the 11th of October 2023), though at the time it was using net 7.0...

EDIT2: I've already tried adding the runtime identifier to the server web apps (which host Blazor wasm app) and now those projects to build. However, the others that are shared between the WASM Blazor app web app still fail with the same error.

EDIT3: Just to add that the equivalent command (dotnet publish SRA.Assistencias.Rest.csproj -o $destination --self-contained -r win-x64 runs without any issues from a Windows 11 pro machine).

EDIT4: Just to add that removing the self-contained option fixes the issue (ie, publishing/building in a framework-dependent manner does not result in any build error).

Thanks.

• azure-devops
• nuget-package-restore
• dotnet-publish

2 Answers 2

In the end, my good friend Joao saved the day by finding the Nuget Authentication task.

Based on the further discussions and your update, you may also consider running the dotnet restore step with the externalFeedCredentials property. This ensures authentication against the NuGet service connection when accessing your private feed.

- task: DotNetCoreCLI@2
  inputs:
    command: 'restore'
    projects: '$(System.DefaultWorkingDirectory)/xxxAppDemo/xxxAppDemo.csproj'
    restoreArguments: '-r win-x64'
    feedsToUse: 'config'
    nugetConfigPath: '$(System.DefaultWorkingDirectory)/nuget.config'
    externalFeedCredentials: 'xxxNuGetSvcCnn'
    restoreDirectory: '$(System.DefaultWorkingDirectory)/NuGet'

The --no-restore flag for dotnet publish step is still recommended due to prevent the implicit restore behavior as mentioned earlier.

Based on your description, it appears that dotnet restore successfully retrieved the packages from the expected sources, but dotnet publish failed during its own restore step. To resolve this, consider adding the --no-restore flag to the arguments property of dotnet publish. This approach is recommended in the documentation: Why is my build, publish, or test step failing to restore packages?.

Most dotnet commands, including build, publish, and test include an implicit restore step. This will fail against authenticated feeds, even if you ran a successful dotnet restore in an earlier step, because the earlier step will have cleaned up the credentials it used.

To fix this issue, add the --no-restore flag to the Arguments textbox.

This ensures that dotnet publish does not attempt to restore packages again, avoiding potential authentication issues.